Repository navigation
Know #load'ed F# scripts in diagnostics, hover and completions - #133
Merged
Merged
Conversation
After a cell ran #load, a later cell that used the loaded script reported FS0039 in the editor, though FSI ran it fine: Lib.triple after loading a script headed module Lib, or Noheader.quad after loading noheader.fsx. The loaded file's text was appended to the virtual document as if it were an executed cell, where a module or namespace header is not valid inside the fragment module and nothing carries the name FSI gives a headerless script. A verbatim @"..." path was not recognised at all, and every loaded file was appended again on each later execution. FSI compiles a loaded script as a file of its own, under its module or namespace header or, with none, a module named for the file, and does not open it unless it is marked AutoOpen. The checker treats a script's files the same way when they are part of the project, so a load that runs now adds its files, nested loads included, ahead of the notebook in the project options instead of copying the text in. The checker works out that closure itself, so a nested #load resolves against the file it is in, as it does in FSI. Only a cell that ran records its loads. The line scan that lifts directives out of an executed fragment and repeats its opens also treated lines inside a multi-line string or comment, or in a branch #if leaves out, as code. It now carries the F# tokenizer's state from line to line and skips those lines. Signed-off-by: Torrey Betts <torrey.betts@gmail.com>
SummarySummary
CoverageVerso - 82.2%
Verso.Abstractions - 84.2%
Verso.Ado - 81.4%
Verso.Blazor - 31.4%
Verso.Blazor.Shared - 62.6%
Verso.Cli - 41.4%
Verso.DataFrame - 82.3%
Verso.FSharp - 82.6%
Verso.Host - 58.7%
Verso.Http - 76.2%
Verso.JavaScript - 59.8%
Verso.PowerShell - 64.7%
Verso.Python - 78.1%
Verso.Sample.Diagram - 80.1%
Verso.Sample.Dice - 82.2%
Verso.Sample.Slides - 58.8%
Verso.Sample.Sparkline - 67.3%
Verso.Testing - 79.4%
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This follows up #129. After a cell ran
#load, the editor still didn't know the loaded script: a later cell usingLib.triple(script headedmodule Lib) orNoheader.quad(headerlessnoheader.fsx) showed FS0039, even though FSI ran it fine. The kernel was pasting the loaded file's text into the virtual document as if it were a cell, so the header didn't fit inside the fragment module and nothing gave a headerless script the name FSI gives it. Verbatim@"..."paths weren't picked up at all.Before changing anything I checked through the kernel what FSI really does. It compiles a loaded script as a file of its own, under its
moduleornamespaceheader, or a module named for the file when there is no header. It doesn't open it, so barequadfails in FSI too, unless the module is[<AutoOpen>]. A nested#loadresolves against the file it's in. So now a load that runs adds its files to the checker's project, ahead of the notebook, and the checker works out the nested closure itself. Only a cell that ran records its loads.While in there I made the fragment line scan string-aware. A line inside a multi-line string or comment, or in a branch
#ifleaves out, is no longer lifted as a directive or repeated as anopen. The scan carries the F# tokenizer's state from line to line, so there's no hand-rolled lexer.Tests added:
moduleheader, without a header, with anamespaceheader, and with an[<AutoOpen>]module#loadresolved against the notebook directoryopeninside a triple-quoted string, a verbatim string, a block comment and an inactive#elsebranch is not opened later#rline inside a multi-line string stays in the stringI also updated the existing
LoadDirective_AddsFileContentsToIntelliSensetest. It expected a loaded name to complete unqualified, which FSI doesn't allow.