Skip to content
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

Allow mixed declaration and assignment in deconstruction #44476

Merged

Conversation

YairHalberstadt
Copy link
Contributor

@YairHalberstadt YairHalberstadt commented May 21, 2020

Implements dotnet/csharplang#125
Test plan: #47746

I simply removed the error, and added tests. So far everything seems to work without any actual code changes, which worries me a little :-)

Please suggest scenarios for further testing.

@YairHalberstadt YairHalberstadt requested a review from a team as a code owner May 21, 2020 11:15
@RikkiGibson
Copy link
Contributor

RikkiGibson commented May 21, 2020

are there any tests for nested deconstruction? i.e. (var x, (var y, z)) = new C(); #Resolved

@RikkiGibson RikkiGibson added Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee. labels May 21, 2020
@RikkiGibson
Copy link
Contributor

do we need to retarget this to a "compiler-next" branch? @jaredpar

@YairHalberstadt
Copy link
Contributor Author

YairHalberstadt commented May 21, 2020

are there any tests for nested deconstruction? i.e. (var x, (var y, z)) = new C();

Thanks, added a test #Resolved

@jcouv
Copy link
Member

jcouv commented May 27, 2020

So far everything seems to work without any actual code changes [just removing the error]

That's what we expected :-)

Just as a heads up, we likely won't have much time to review this PR before 6/10 (we're trying to get a big chunk of records in next preview).
Also, we'll want to double-check this feature by LDM. I don't feel strongly opposed, but I still don't much like the idea of mixing from a readability point of view :-/ #Resolved

@alrz
Copy link
Member

alrz commented May 28, 2020

Is there any consideration to permit tuple element names in deconstruction? The expected behavior is already established by recursive patterns for both Deconstruct and tuples. See dotnet/csharplang#3304

@YairHalberstadt
Copy link
Contributor Author

@alrz

I don't see why that's related? This just removes a (somewhat arbitrary) error.

@alrz
Copy link
Member

alrz commented May 28, 2020

I don't see why that's related? This just removes a (somewhat arbitrary) error.

I believe this is also a syntactical relaxation for deconstruction and removes an error. The parser already accept such code.

@jcouv jcouv self-assigned this Jun 3, 2020
@jcouv
Copy link
Member

jcouv commented Sep 15, 2020

LDM approved yesterday for language version following C# 9 (9/15/2020). #Resolved

Copy link
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done with review pass (iteration 5)

@RikkiGibson
Copy link
Contributor

RikkiGibson commented Sep 15, 2020

The feature is approved as preview feature for C# 10 (VS 16.9 under LangVersion.Preview). If this PR is to be merged in the next couple of weeks, then it will be necessary to update the base branch to release/dev16.9-preview1 (tenatively named).

If on the other hand it will be a while before the PR is merged, we can just wait until master represents VS 16.9.

/cc @jaredpar #Resolved

@YairHalberstadt
Copy link
Contributor Author

The feature is approved as preview feature for C# 10 (VS 16.9 under LangVersion.Preview). If this PR is to be merged in the next couple of weeks, then it will be necessary to update the base branch to release/dev16.9-preview1 (tenatively named).

Would it not be possible to merge it now as a preview feature for C# 10? All the current C# 9 features are no longer in preview. There's zero risk of breaking C# 9.0 since all this does is replace a warning with a preview gate - no code gen changes at all.

Otherwise might as well wait a couple of weeks.

Either way I imagine that there's further tests that need to be done before this can be merged:

Off the top of my head I'm guessing Symbols and Control flow tests? Anything else? GoToDefinition tests?

@jcouv
Copy link
Member

jcouv commented Sep 16, 2020

Yes, we discussed with Rikki offline and I think we can use the master branch right away since the feature is behind LangVer=preview.

Either way I imagine that there's further tests that need to be done before this can be merged

Yes. I opened a mini test-plan issue for tracking. I think we can just do the whole feature in a single PR.

For IDE side, I'll start a thread and get back to you.

From the compiler side:

  • A data flow test would be good (a test in the vein of RegionAnalysisTests.AnalysisOfExpressionInTupleEquality).
  • Let's check the semantic model in nested scenario (see VerifyModelForDeconstructionLocal which covers declaration, and add checks for GetTypeInfo and GetSymbolInfo on variables used in mixed declarations).
  • Add an IOperation test

@RikkiGibson RikkiGibson requested review from a team and removed request for a team September 23, 2020 13:25
Copy link
Member

@333fred 333fred left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (commit 13). I'm not exactly sure when we'll be able to get this merged, hopefully sometime in the next week or 2. We're heads down on remaining C# 9 fixes for the next 2 weeks.

@YairHalberstadt
Copy link
Contributor Author

@333fred any chance we can get this merged this week?

Copy link
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM Thanks (iteration 14)

@333fred
Copy link
Member

333fred commented Oct 14, 2020

Next week.

@jcouv
Copy link
Member

jcouv commented Dec 10, 2020

Sorry for the delay. I'm going to run an IDE test pass today and find an IDE buddy.

@jcouv
Copy link
Member

jcouv commented Dec 14, 2020

Ran this change through a quick IDE test pass on Friday, focusing on completion and QuickInfo (since those seems most likely to be affected). Things look good (behavior is same as for regular deconstruction). Pinged Jinu to get an buddy to get the IDE sign-off.

@sharwell
Copy link
Member

sharwell commented Jan 19, 2021

It looks like there are several test gaps in IDE code. They aren't new for this PR, but we should take the opportunity to close them.

  • VarKeywordRecommenderTests, IntKeywordRecommenderTests, etc., should be updated:
    • Verify keyword is provided for (x, $$
    • Verify the keyword is not provided for var (x, $$
  • SymbolCompletionProviderTests needs to be updated to explicitly test (var x, $$ (reference provided) and var (x, $$ (reference not provided). See TupleTypeAtMemberLevel3 for an example and positioning within the file.
    • Verify that x is not provided for (var x, $$ (while other symbols are)
  • Consider extending the above examples to cover nested deconstruction.

[jcouv update:] Sam also suggested to verify (var x, x) = (1, 2); and (var _, _) = (0, 0);. I don't recall if we covered that.

@YairHalberstadt
Copy link
Contributor Author

Looks like (var _, _) = (0, 0); is allowed today. I have absolutely no idea why, but it would be a breaking change to remove.

@YairHalberstadt
Copy link
Contributor Author

As is:

        (var x, _) = (0, 0);
        Console.WriteLine(x);

So it looks like mixed declaration and discard has always been allowed.

@YairHalberstadt
Copy link
Contributor Author

Verify that x is not provided for (var x, $$ (while other symbols are)

Currently the logic to check is a local is in scope simply checks that's it's declared before the current syntax, so this is suggested, as is x in var x = $$.

I don't want to change that logic in the PR as it seems like a relatively complex change, and we do this already, so we're no worse off by merging this.

@sharwell
Copy link
Member

How does the language define this code after your feature?

class T {
  int x;
  void M() {
    (var x, x) = (1, 2);
    Console.WriteLine(x);
    Console.WriteLine(this.x);
  }
}

@YairHalberstadt
Copy link
Contributor Author

@sharwell that's an error

@sharwell
Copy link
Member

And (x, var x) there would also be an error?

@YairHalberstadt
Copy link
Contributor Author

Yes, and I have tests for both

@jcouv
Copy link
Member

jcouv commented Jan 27, 2021

@sharwell We have the necessary sign-offs from the compiler side. Yair has added the IDE (thanks!) and they match what I'd verified manually (behave as expected).
We're ready to merge if you're all good. Thanks

@jcouv jcouv merged commit c3b8b10 into dotnet:master Jan 28, 2021
@ghost ghost added this to the Next milestone Jan 28, 2021
333fred added a commit to 333fred/roslyn that referenced this pull request Jan 28, 2021
* upstream/master:
  For the purpose of runtime capability check require RuntimeFeature type to be a static class. (dotnet#50829)
  Allow mixed declaration and assignment in deconstruction (dotnet#44476)
  Disable sdl
  Fix crash around handling delegating of constructors cross-project
  Clarify in a comment when some stuff loads
  Don't reference the implementation type directly if we don't need it
  Remove the CreateWorkspace() method that implies it's created there
  Delete AbstractPackage`2.IsInIdeMode()
  Remove some very outdated comments
@jcouv
Copy link
Member

jcouv commented Jan 28, 2021

Merged/squashed. Thanks @YairHalberstadt! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

7 participants