TransparentCompiler: scripts read #load'ed files through the global FileSystem, and DocumentSource.Custom gives new versions on every call
Les mainteneurs répondent en général sous 2 jours
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 8/100
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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?
- Langage dominant
- F#
- Étoiles
- 4.3k
- Forks
- 884
- Merge moyen
- 2 j 11 h
- PR mergées (30 j)
- 73
Préparer son environnement
Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de dotnet/fsharp
-
Needs-Triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 95/100
Les mainteneurs répondent en général sous 2 jours
-
Semantic classification cache for opened documents is never populated (written to the unopened-documents cache)Peut-être pris @xperiandri l’a pris il y a 69 jours. OuverteNeeds-Triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
Les mainteneurs répondent en général sous 2 jours
-
Needs-Triage
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
dotnet/fsharp#20265 · 1 commentaire ·
Les mainteneurs répondent en général sous 2 jours
-
Bug Needs-Triage
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 2 jours
-
Needs-Triage
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
Les mainteneurs répondent en général sous 2 jours
Toutes les issues de dotnet/fsharp
Issues similaires
-
from-agent
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
-
code quality wasm backend
Difficulté 1/5 Moins d'une heure Accessibilité débutants 84/100
nanyx-lang/nanyx#930 ·
Les mainteneurs répondent en général sous 1 jour
-
[mlir][math] math-expand-ops computes math.ctlz wrongly for widths that are not a power of twoOuvertemlir
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
llvm/llvm-project#241891 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
arrays bug intrinsic llvm medium priority wrong result
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
Les mainteneurs répondent en général sous 1 jour
-
`lower_throw!` treats any function whose name contains `jl_error` etc. as a throw (kernel becomes a trap / segfault)Peut-être pris @sasmith-14 l’a pris il y a 1 jour. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
JuliaGPU/GPUCompiler.jl#1088 ·
Les mainteneurs répondent en général sous 1 jour