-
Notifications
You must be signed in to change notification settings - Fork 832
Finding / renaming parameters with signature files #14554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
… parameter references
dsyme
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've discussed with @0101 . One more change is needed (more to cenv not TcEnv) but otherwise this is fine. Marking as approved.
|
Ok, so after moving I couldn't entirely pinpoint where the issue originates, but it did go away when I cleared It also goes away when we don't auto-generate signatures with the ProjectGeneration framework: fsharp/tests/FSharp.Test.Utilities/ProjectGeneration.fs Lines 424 to 429 in cf810fe
So something sketchy is probably happening either in IncrementalBuilder or in ProjectGeneration. Either way that shouldn't be affected by this PR. So I propose to adjust the tests to avoid the problem (removing auto-generation of signatures, which is the likely culprit) and merging it. The cache in |
Seems very reasonable! |
Fixes #14277
We add
OtherRange optiontoArgReprInfoand addArgReprInfo optiontoValOptionalData. Then we're able to propagate signature location fromSignatureConformanceto the parameterVals in lambdas.With this we can tell we're looking at a parameter which is also in a signature file when processing
Symbol.IsPrivateToFileand newSymbol.IsPrivateToFileAndSignatureFileWe can use
Symbol.IsPrivateToFileAndSignatureFilein VS when finding references to only look at the two corresponding files instead of going through all of them.This still doesn't work for method parameters, because the
OtherRangeis not propagated to the correct instance ofArgReprInfothere for some reason. Created a separate issue for that: #14753. But at least renaming the parameter in signature file no longer produces an error dialog.