Keep parsed lambda patterns and expression in syntax tree #10166
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.
Keeps initially parsed lambda patterns and expressions in the syntax tree.
The parser replaces patterns and expression with iterated lambdas that are later used by the type checker and code generation. Ideally this conversion should be done at a later stage, so the syntax tree keeps the actually parsed data instead. Doing so would make a lot of churn, since at this point every other part of the compiler already assumes to work with the iterated lambdas.
The problem with this early conversion approach is tools interested in the syntax tree try to "reconstruct" the original lambdas, each one using a different approach (e.g. FSharpLint, Fantomas). This may be error-prone due to in some of the cases the compiler effectively throws the tree data away (by stripping parens and errors in various cases).
This PR adds another field to
SynExpr.Lambda
so tooling interested in the syntax tree would be able to work with parsed data.Other possible approaches:
SynExpr.Lambda
intoLambda
andIteratedLambda
cases (cluttersSynExpr
, less obvious meaning, more churn)