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

[semi-auto-props]: Support assigning properties from constructor #60601

Merged
merged 42 commits into from
May 12, 2022

Conversation

Youssef1313
Copy link
Member

@Youssef1313 Youssef1313 commented Apr 6, 2022

Test plan: #57012

cc @AlekseyTs @333fred

Note: Code I modified is used for both allowing assigning from constructors and also for some data flow. Changes made here were more focused on the first part. Meaning that it could be not correct for data flow which (if possible) I want to leave for now (there are PROTOTYPE comments there).

This implements the following part from LDM notes:

Properties can be assigned in the constructor of a type if that property has a setter, or is a get-only property whose backing field will be emitted.

And also, from the original proposal:

If the auto-property does not have a set accessor, the backing field can still be assigned to in the body of a constructor of the enclosing class. Such an assignment assigns directly to the backing field of the property.

@Youssef1313 Youssef1313 requested a review from a team as a code owner April 6, 2022 07:04
@ghost ghost added the Community The pull request was submitted by a contributor who is not a Microsoft employee. label Apr 6, 2022
@AlekseyTs
Copy link
Contributor

AlekseyTs commented Apr 6, 2022

Has "auto-default struct" feature made it to the feature branch? It feels like it might impact some initialization scenarios.


In reply to: 1090276403

@Youssef1313
Copy link
Member Author

@AlekseyTs I think it got into 17.3 branch but not in main. So it didn't get in features/semi-auto-props yet

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Apr 6, 2022

I think it got into 17.3 branch but not in main. So it didn't get in features/semi-auto-props yet

We should consider integrating main-vs-deps directly into the feature branch then. I think some of the design decisions around this feature were made assuming the "auto-default struct" feature is in place.


In reply to: 1090313856

@Youssef1313
Copy link
Member Author

@AlekseyTs I opened #60603.

@Youssef1313 Youssef1313 closed this Apr 8, 2022
@Youssef1313 Youssef1313 reopened this Apr 8, 2022
@Youssef1313
Copy link
Member Author

@AlekseyTs This is ready for review. Can you take a look please? Thanks!

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Apr 8, 2022

This is ready for review.

Is the expected behavior clearly described in the feature specification (a link to the relevant section would be good). Otherwise, it would be good to clearly describe in details what behavior this PR is implementing so that reviewers could "compare" the intent and the implementation.


In reply to: 1093069013

@Youssef1313
Copy link
Member Author

@AlekseyTs I updated the PR description. Thanks!

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Apr 12, 2022

CC @333fred


In reply to: 1096978766

@Youssef1313
Copy link
Member Author

@AlekseyTs @333fred This should be ready for another look.

@Youssef1313
Copy link
Member Author

Youssef1313 commented May 3, 2022

@AlekseyTs CI is still failing after it was restarted. The failure doesn't seem related to the changes. Should a complete new build be started?

@AlekseyTs
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@AlekseyTs
Copy link
Contributor

AlekseyTs commented May 4, 2022

CC @333fred


In reply to: 1117314610

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.

Overall this is looking good to me. Just a minor refactor suggestion. (commit 36)

src/Compilers/CSharp/Portable/Symbols/BaseTypeAnalysis.cs Outdated Show resolved Hide resolved
@@ -202,6 +202,9 @@ private void SetGlobalErrorIfTrue(bool arg)
new LocalizableResourceString(messageResourceName, CodeAnalysisResources.ResourceManager, typeof(CodeAnalysisResources)));
}

addCircularStructDiagnostics(compilation.GlobalNamespace);
Copy link
Contributor

@AlekseyTs AlekseyTs May 5, 2022

Choose a reason for hiding this comment

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

compilation.GlobalNamespace

It looks like we are traversing things from added modules and referenced assemblies. See methodCompiler.CompileNamespace call above. #Closed

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah compilation.GlobalNamespace is alot of unnecessary work. I'm switching to compilation.SourceModule.GlobalNamespace. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah compilation.GlobalNamespace is alot of unnecessary work.

It not only a lot of unnecessary work, but also the work that is likely to have negative impact on referenced compilations (work done out of "order").

@AlekseyTs
Copy link
Contributor

Done with review pass (commit 37)

@AlekseyTs
Copy link
Contributor

AlekseyTs commented May 5, 2022

Done with review pass (commit 38). Besides code changes, I am still tracking this thread for tests #60601 (comment).

@Youssef1313
Copy link
Member Author

@AlekseyTs

diagnostics.AddRange(compilation.CircularStructDiagnostics);

It looks like diagnostics isn't guaranteed to have dependencies bag while CircularStructDiagnostics does, causing this assert to fail:

Debug.Assert(allowMismatchInDependencyAccumulation || !other.AccumulatesDependencies || this.AccumulatesDependencies);

I passed allowMismatchInDependencyAccumulation: true since we can have a dependencies bag for diagnostics. But let me know if you think this is wrong.

@Youssef1313
Copy link
Member Author

Done with review pass (commit 38). Besides code changes, I am still tracking this thread for tests #60601 (comment).

Responded with a question on it.

Thanks a lot for the review and the help you're providing. I very much appreciate it.

@AlekseyTs
Copy link
Contributor

I passed allowMismatchInDependencyAccumulation: true since we can have a dependencies bag for diagnostics.

That is the right thing to do in our situation.


In reply to: 1119065377

@AlekseyTs
Copy link
Contributor

Done with review pass (commit 40)

@AlekseyTs
Copy link
Contributor

@Youssef1313 It looks like there is merge conflict to resolve.

@Youssef1313
Copy link
Member Author

Youssef1313 commented May 12, 2022

@333fred @AlekseyTs Is this ready to merge? For the next PR*, I'm planning to address small prototype comments (e.g, renaming ContainsFieldKeyword). Then I'm not sure if I should start working on mixed scenarios?

*I can get to the next PR in few days. So feel free if someone wants to take some work over before I do.

Copy link
Contributor

@AlekseyTs AlekseyTs 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 42)

@333fred 333fred merged commit 5dc2199 into dotnet:features/semi-auto-props May 12, 2022
@Youssef1313 Youssef1313 deleted the semi-assign-ctor branch May 12, 2022 17:14
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
None yet
Development

Successfully merging this pull request may close these issues.

3 participants