(minimal, patching-over fix) async rules crash under the TransparentCompiler#862
Open
michaelglass wants to merge 1 commit into
Open
Conversation
…er check results FSharpProjectContext.get_ProjectOptions() throws by design when the check results come from FCS's TransparentCompiler (as used by some analyzer hosts). Rules that force the two-phase ProjectOptions lazy (the library heuristics in AsynchronousFunctionNames, SimpleAsyncComplementaryHelpers, NoAsyncRunSynchronouslyInLibrary) then abort linting of the whole file with an internal error. Wrap the single lazy construction site in try/with -> None so those heuristics fall back gracefully instead of failing the file. Regression: TestApi lints TransparentCompiler-produced parse+check results and asserts no ProjectProgress.Failed is reported.
michaelglass
changed the title
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
1 participant
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.
When this happens
If you run FSharpLint as a library — the
lintParsedFile/lintParsedSourceAPI, passing your ownProjectCheckResults— and those results come from anFSharpCheckercreated withuseTransparentCompiler = true, linting aborts on otherwise-valid files with an internal error. The trigger is the async/library-heuristic rules:AsynchronousFunctionNames,SimpleAsyncComplementaryHelpers, andNoAsyncRunSynchronouslyInLibrary(the first and last are on by default).Concretely: in my project FsHotWatch I use FSharpLint as a library (not the CLI tool), reusing warm FCS check results to re-lint files on save. When I switched the underlying
FSharpCheckerto the TransparentCompiler, valid files started failing to lint with an internal error.Why
Those rules need the project file name. They get it through the two-phase
ProjectOptionslazy (added in91fd00b0), which readsFSharpProjectContext.ProjectOptions— a getter that throws by design under the TransparentCompiler. Forcing the lazy then raises, and FSharpLint reports the whole file as failed.Fix
Wrap the single
ProjectOptionslazy intry … with _ -> None, so those rules fall back to their non-project heuristics instead of failing the file. One change at the source of the shared lazy, so every rule that uses it benefits.Test
TestApi.fsregression: lints results produced byFSharpChecker.Create(useTransparentCompiler = true)and asserts no internal failure — it reproduces the crash without the fix and passes with it.if it wasn't obvious from the tone of the PR: this work was done with the extensive help with AI, and then eyeballed / confirmed by a fleshy human being