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

Revise the shape of the syntax trees for property patterns #9505

Merged
merged 8 commits into from
Mar 9, 2016

Conversation

gafter
Copy link
Member

@gafter gafter commented Mar 5, 2016

Fixes #9371
Related to #9284

@CyrusNajmabadi This should unblock the IDE work. Please review.
@AlekseyTs @jaredpar Please review
@dotnet/roslyn-compiler FYI

@gafter gafter added Area-IDE Concept-API This issue involves adding, removing, clarification, or modification of an API. Area-Compilers 4 - In Review A fix for the issue is submitted for review. New Language Feature - Pattern Matching Pattern Matching labels Mar 5, 2016
@gafter gafter self-assigned this Mar 5, 2016
@gafter gafter added this to the 2.0 (Preview) milestone Mar 5, 2016
@CyrusNajmabadi
Copy link
Member

IDE and syntax changes LGTM.

@@ -123,7 +123,8 @@ private BoundPattern BindRecursivePattern(RecursivePatternSyntax node, BoundExpr
var builder = ArrayBuilder<BoundSubPropertyPattern>.GetInstance(properties.Length);
for (int i = 0; i < properties.Length; i++)
{
builder.Add(new BoundSubPropertyPattern(node.PatternList.SubPatterns[i], properties[i].GetTypeOrReturnType(), properties[i], LookupResultKind.Empty, boundPatterns[i], hasErrors));
var member = new BoundPropertyPatternMember(node.PatternList.SubPatterns[i], properties[i], ImmutableArray<BoundExpression>.Empty, ImmutableArray<string>.Empty, ImmutableArray<RefKind>.Empty, false, default(ImmutableArray<int>), LookupResultKind.Empty, properties[i].GetTypeOrReturnType(), hasErrors);
Copy link
Contributor

Choose a reason for hiding this comment

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

This line is way too long, consider adding line breaks.

@CyrusNajmabadi
Copy link
Member

I'd actually go the opposite route. I'd allow parsing out any sort expressions within these pattersn. Then i'd give a higher level error saying which legal expressions you can use (currently only "x is Blah" expressions).

@CyrusNajmabadi
Copy link
Member

But i don't feel strongly about it.

@gafter
Copy link
Member Author

gafter commented Mar 5, 2016

@CyrusNajmabadi I agree, that is reasonable, but I wasn't ready to write the recovery code today. I was ready to put the syntax trees in place to allow that later.

@CyrusNajmabadi
Copy link
Member

@gafter Makes sense to me. I like that the syntax is relaxed but we can then adjust the implementation as we want in the future.

{
// TODO: consider refactoring out common code with BindObjectInitializerMember

BoundImplicitReceiver implicitReceiver = new BoundImplicitReceiver(memberName.Parent, patternType);
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider marking this node as compiler generated?

Copy link
Member Author

Choose a reason for hiding this comment

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

There is no need, as it is not put into the bound tree that results from the binder. It is only used to facilitate lookup.

@AlekseyTs
Copy link
Contributor

Test prtest/win/dbg/unit32 please.
http://dotnet-ci.cloudapp.net/job/roslyn_prtest_win_dbg_unit32/4888/

@AlekseyTs
Copy link
Contributor

Test prtest/win/dbg/eta please.
http://dotnet-ci.cloudapp.net/job/dotnet_roslyn_prtest_win_dbg_eta/4841/


case BoundKind.EventAccess:
// TODO: Should a property pattern be capable of referencing an event?
// https://github.com/dotnet/roslyn/issues/9515
Copy link
Contributor

Choose a reason for hiding this comment

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

It might make sense to allow referencing a field-like event from within a type that declares it (this is not a suggestion to handle this case in this change).

Copy link
Member Author

Choose a reason for hiding this comment

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

That is already on the open issue list for the LDM.

Copy link
Contributor

Choose a reason for hiding this comment

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

That is great, consider this comment as an opinion.

@AlekseyTs
Copy link
Contributor

@gafter I am done with a review pass.

@gafter
Copy link
Member Author

gafter commented Mar 8, 2016

@AlekseyTs This has been updated per review.
@jaredpar Second review needed, please. IDE work is blocked on this.

var subProperty = pat.Subpatterns[i].Property;
// TODO: review and test this code path.
// https://github.com/dotnet/roslyn/issues/9542
var subProperty = (pat.Subpatterns[i].Member as BoundPropertyPatternMember)?.MemberSymbol;
Copy link
Contributor

Choose a reason for hiding this comment

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

The #9542 doesn't capture the issue brought up against this line of code during code review. It should specifically talk about replacement of an as cast with a "normal" type cast because this conversion is not expected to fail. Please make sure the issue captures this information.

Copy link
Contributor

Choose a reason for hiding this comment

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

Another part was removal of conditional access off of subProperty, it is not expected to have null value.

Copy link
Member Author

Choose a reason for hiding this comment

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

I will expand the comment just above.

Copy link
Contributor

Choose a reason for hiding this comment

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

That would be a viable alternative.

@gafter
Copy link
Member Author

gafter commented Mar 8, 2016

All comments responded to. Please re-review. IDE work for Build is still blocked on this API change.

@AlekseyTs
Copy link
Contributor

LGTM. However, we should make sure that outlined error scenarios (events, methods, nested types) are covered by unit-tests before this change makes it into the 'future'.

@gafter
Copy link
Member Author

gafter commented Mar 8, 2016

@dotnet/roslyn-compiler Can I please have another set of eyes on this from the compiler team?

diagnostics: diagnostics);

LookupResultKind resultKind = boundMember.ResultKind;
bool hasErrors = boundMember.HasAnyErrors || implicitReceiver.HasAnyErrors;
Copy link
Member

Choose a reason for hiding this comment

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

Consider moving bool hasErrors = ... below if block so that hasErrors can be calculated once.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea.

@cston
Copy link
Member

cston commented Mar 8, 2016

LGTM

gafter added a commit that referenced this pull request Mar 9, 2016
Revise the shape of the syntax trees for property patterns
@gafter gafter merged commit af8900c into dotnet:features/patterns Mar 9, 2016
@gafter gafter deleted the patterns-9371 branch May 24, 2018 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 - In Review A fix for the issue is submitted for review. Area-Compilers Area-IDE cla-already-signed Concept-API This issue involves adding, removing, clarification, or modification of an API. New Language Feature - Pattern Matching Pattern Matching
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants