TransparentCompiler: scripts read #load'ed files through the global FileSystem, and DocumentSource.Custom gives new versions on every call
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 8/100
Línea de trabajo
Start with GetProjectSnapshotFromScript in src/Compiler/Service/service.fs, then the version logic in CreateFromDocumentSource in FSharpProjectSnapshot.fs and the None fallback in FSharpSource.fs. The issue asks maintainers to choose between several designs, so there is no single fix to make yet. Done means a decision on the API shape and a stable version scheme, with the TransparentCompiler caching and script #load behaviour covered by tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
FsAutoComplete installs a process-wide FileSystemAutoOpens.FileSystem shim so FCS reads the in-memory text of open files. We would like to stop doing that and give each checker its own view of the files (ionide/FsAutoComplete#1555). With the TransparentCompiler, project files already come from snapshots we build ourselves. Scripts are the part that still goes through the global file system, and the per-checker alternative, DocumentSource.Custom, does not work well there yet.
Links are to main at 409c7a62.
1. GetProjectSnapshotFromScript ignores the checker's document source
FSharpChecker.GetProjectSnapshotFromScript falls back to DocumentSource.FileSystem when no documentSource is passed, also when the checker was created with DocumentSource.Custom (service.fs#L533). The TransparentCompiler's GetProjectOptionsFromScript always passes DocumentSource.FileSystem (TransparentCompiler.fs#L2377). So the files a script #loads are read through the global file system (FSharpProjectSnapshot.fs#L81-L89).
2. A custom document source gives every file snapshot a new version
FSharpFileSnapshot.CreateFromDocumentSource uses DateTime.Now.Ticks as the version (FSharpProjectSnapshot.fs#L95). Each call creates new versions for files that did not change, so the TransparentCompiler caches miss. This happens for:
- the
#loaded files whenGetProjectSnapshotFromScriptis givenDocumentSource.Custom(TransparentCompiler.fs#L2483); - every
FSharpProjectOptionsbased call on a TransparentCompiler created withDocumentSource.Custom, throughFSharpProjectSnapshot.FromOptions(FSharpProjectSnapshot.fs#L715-L738).
3. None from a custom document source throws
When the function returns None, CreateFromDocumentSource fails with "Couldn't get source for file" (FSharpProjectSnapshot.fs#L104). The BackgroundCompiler reads the file from disk in that case (FSharpSource.fs#L69-L77). An editor only knows the text of its open files, so with the TransparentCompiler it has to read every other file itself.
Possible changes
- Use the checker's document source in
GetProjectSnapshotFromScriptwhen none is passed. - Let a custom source return a version with the text, or use a stable version, for example the last write time for files read from disk.
- Treat
Noneas "read from the file system", as the BackgroundCompiler does. - Or, for the snapshot API: let the caller create the snapshots of the
#loaded files (astring -> Async<FSharpFileSnapshot>callback), as it already does for project files.
documentSource on FSharpChecker.Create is marked experimental and "likely to be removed in the future" (service.fsi#L53). If that is still the plan, which way should an editor give the TransparentCompiler the text of open files that a script #loads?
- Lenguaje dominante
- F#
- Estrellas
- 4.3k
- Forks
- 884
- Merge medio
- 2 d 11 h
- PR fusionados (30 d)
- 73
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una 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 dotnet/fsharp
-
Needs-Triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
Los mantenedores suelen responder en 2 días
-
Semantic classification cache for opened documents is never populated (written to the unopened-documents cache)Posiblemente ocupada @xperiandri la tomó hace 69 días. AbiertoNeeds-Triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 2 días
-
Needs-Triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dotnet/fsharp#20265 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Bug Needs-Triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 2 días
-
Needs-Triage
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 2 días
Todos los issues de dotnet/fsharp
Issues similares
-
from-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
code quality wasm backend
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
nanyx-lang/nanyx#930 ·
Los mantenedores suelen responder en 1 día
-
[mlir][math] math-expand-ops computes math.ctlz wrongly for widths that are not a power of twoAbiertomlir
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
llvm/llvm-project#241891 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
arrays bug intrinsic llvm medium priority wrong result
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
`lower_throw!` treats any function whose name contains `jl_error` etc. as a throw (kernel becomes a trap / segfault)Posiblemente ocupada @sasmith-14 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
JuliaGPU/GPUCompiler.jl#1088 ·
Los mantenedores suelen responder en 1 día