Prevent parent scope symbols leaking into module's scope
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
Línea de trabajo
Comienza rastreando la búsqueda de símbolos en la pila de ámbitos y create_default_context(), y luego inspecciona cómo se representan FrameType y constantes como NU_LIB_DIRS. Decide cómo deberían interactuar los frames Barrier y Prelude con el aislamiento de módulos, los comandos predeterminados y las superposiciones de nupm. Se considera terminado cuando las reglas de búsqueda y el comportamiento de NU_LIB_DIRS estén especificados e implementados, con cobertura para símbolos padre, comandos de Prelude e importaciones de módulos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Leaking user-defined symbols from a parent scope to a module's scope can lead to subtle bugs. The module's scope should be as isolated from the parent scope as possible, but not completely (e.g., we still need basic Nushell commands like ls to be visible).
Could be partially addressed by introducing two new FrameTypes:
Barrier: Stops symbol lookup when traversing the scope stack. This prevents the symbol lookup from searching the parent scopes.Prelude: With only Barrier, we'd lose “default” commands that we want to be visible (likels). Perhaps we could have a Prelude frame type which would get initialized first duringcreate_default_context()with these default commands.
The question is what to do with constants like NU_LIB_DIRS, e.g.,:
const NU_LIB_DIRS = $NU_LIB_DIRS | append '/home/spam/foo`
module {
use bar.nu # should it look for 'bar.nu' in '/home/spam/foo'?
}
We might want to decide on this based on the envisioned functionality of how nupm is supposed to use overlays as “virtual environments”, relying on modifying the NU_LIB_DIRS constant.
- Lenguaje dominante
- Rust
- Estrellas
- 36
- Forks
- 11
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de nushell/new-nu-parser
-
Suppot parsing bulit-in keywordsAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
nushell/new-nu-parser#64 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
nushell/new-nu-parser#60 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 42/100
nushell/new-nu-parser#59 ·
-
bug typechecker
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
nushell/new-nu-parser#53 · 11 comentarios ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
nushell/new-nu-parser#47 · 3 comentarios ·
Todos los issues de nushell/new-nu-parser
Issues similares
-
Add a just recipe that runs the workflow linters locallyPosiblemente ocupada @sgamelin la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
good first issue security
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
Status bar: a progress line that keeps the same text (import at 0%) ages out after 8 s and blinksAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
transit-audio/transit#216 ·
-
area: effects devices enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
suhina-daw/suhina-daw#1060 ·
Los mantenedores suelen responder en 1 día