Unify anonymous record fields #18910
Conversation
❗ Release notes requiredCaution No release notes found for the changed paths (see table below). Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format. The following format is recommended for this repository:
If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request. You can open this PR in browser to add release notes: open in github.dev
|
|
I selfishly hope that this doesn't get merged till after I open my spread PR (soon!), since there would be some pretty big merge conflicts :) |
|
One should be very careful with anonymous records, because it's very easy to break backwards compatibility for them by changing how they're emitted. At level when new compiler (with change) won't be able to consume assemblies produced by the old compiler (and probably vice versa). |
Will happily wait for the spread operator PR then :) |
@vzarytovskii Is there a way to add test to ensure the backwards compatibility? |
Good question. I don't think we have harness specifically for testing that. I guess manual testing should be enough. |
I guess best l I can do is to write an ilverify test before and after the changes and compare the generated code |
That won't necessarily show all changes, as they can be in the sigdata as well I think. |
We did postpone refactorings/code reorgs in the past when big work was in progress, and spreading justifies that IMO. |
Not as one of the existing test suites. And then have a test matrix: Driven by global.json and msbuild properties to indicate which project should be build by which SDK//F# compiler respectively. It's a suite which does not exist ATM. |
| braceBarExprCore: | ||
| | LBRACE_BAR recdExprCore bar_rbrace | ||
| { let orig, flds = $2 | ||
| let flds = |
There was a problem hiding this comment.
Is this the right level for motivation here, i.e. unifying the parser code for anons vs records (and reflecting that in SyntaxTree as well) ?
Since the motivation for a refactoring should be to make future changes easier, I would also like to use @brianrourkeboll judgement (since spreading will do work across records and anons) if this change is a change that brings benefits.
There was a problem hiding this comment.
Yes and reuse the new BlockSeparator type so we can have a better error recovery when using the wrong separator.
e.g. instead of showing error FS0039: The value or constructor 'B' is not defined. we should say that the wrong separator is used and guide users to use ; instead of comma.
{| A = 3; B = 4 |}
{| A = 3, B = 4 |}
stdin(5,11): error FS0039: The value or constructor 'B' is not defined.
@T-Gro I think that would be valuable for us moving forward. Even something that Copilot can do for us :) |
Everyone, feel free to add comments and ask for more use cases at #18913 (comment) . I will act as a secretary repeating them to copilot... |
edgarfgp
force-pushed
the
unify-syn-expr-records
branch
from
52bb958 to
5f52cc2
Compare
…nto unify-syn-expr-records # Conflicts: # src/Compiler/Driver/GraphChecking/FileContentMapping.fs # src/Compiler/Service/FSharpParseFileResults.fs # src/Compiler/Service/SynExpr.fs # src/Compiler/SyntaxTree/SyntaxTreeOps.fs
# Conflicts: # tests/ILVerify/ilverify_FSharp.Compiler.Service_Debug_netstandard2.0.bsl # tests/ILVerify/ilverify_FSharp.Compiler.Service_Release_netstandard2.0.bsl
Description
Fixes # (issue, if applicable)
Checklist