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]: Rename ContainsFieldKeyword, revise cases that should handle FieldKeywordBackingField #61310

Merged
merged 16 commits into from
May 24, 2022

Conversation

Youssef1313
Copy link
Member

@Youssef1313 Youssef1313 commented May 13, 2022

Test plan: #57012

@ghost ghost added the Community The pull request was submitted by a contributor who is not a Microsoft employee. label May 13, 2022
@Youssef1313
Copy link
Member Author

@333fred @AlekseyTs For initial review.

@Youssef1313
Copy link
Member Author

Youssef1313 commented May 16, 2022

@AlekseyTs In 1d040e5, I introduced a simple generalized approach for reporting diagnostics that depend on accessor binding. Can you take a look and see if things are good? Thanks!

@Youssef1313 Youssef1313 marked this pull request as ready for review May 16, 2022 09:26
@Youssef1313 Youssef1313 requested a review from a team as a code owner May 16, 2022 09:26
@@ -215,6 +215,7 @@ private FieldSymbol GetActualField(Symbol member, NamedTypeSymbol type)
return (!eventSymbol.HasAssociatedField || ShouldIgnoreStructField(eventSymbol, eventSymbol.Type)) ? null : eventSymbol.AssociatedField.AsMember(type);
case SymbolKind.Property:
// PROTOTYPE(semi-auto-props): Review other event associated field callers and see if we have to do anything special for properties.
// Everything is reviewed except FlowAnalysis.
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 prefer this to be carefully reviewed to make sure I'm not missing anything, as we later will rely on the prototype update that only FlowAnalysis is left.

@Youssef1313
Copy link
Member Author

##[error]The job running on agent Azure Pipelines 70 ran longer than the maximum time of 90 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134

Can someone restart the build? Thanks!

@Youssef1313
Copy link
Member Author

It seems there is a real failure:

  Starting Azure Pipelines Test Run Test_Windows_CoreClr_Debug_Windows.10.Amd64.Open
  Sending Job to Windows.10.Amd64.Open...
  Sent Helix Job; see work items at https://helix.dot.net/api/jobs/46faea75-bd01-4448-b3ce-0b67f5bd14d0/workitems?api-version=2019-06-17
  Waiting for completion of job 46faea75-bd01-4448-b3ce-0b67f5bd14d0 on Windows.10.Amd64.Open
Roslyn Error: test timeout exceeded, dumping remaining processes
Dumping dotnet 1164 to D:\a\1\s\artifacts\log\Debug\dotnet-0.dmp ... succeeded (231701857 bytes)

I'll try to investigate

@Youssef1313
Copy link
Member Author

Youssef1313 commented May 16, 2022

This is the call stack I'm seeing from the dump in CI.

image

@Youssef1313 Youssef1313 reopened this May 16, 2022
@Youssef1313
Copy link
Member Author

There are now different test failures. I'm addressing them separately in #61344

@AlekseyTs
Copy link
Contributor

AlekseyTs commented May 16, 2022

        _ = BackingField?.GetAttributes();

Are we doing the same for the field keyword somewhere?


In reply to: 1127829708


Refers to: src/Compilers/CSharp/Portable/Symbols/Source/SourcePropertySymbolBase.cs:1263 in 1d040e5. [](commit_id = 1d040e5, deletion_comment = False)

public unsafe struct S1
{
public S1* s;
public object P { get => field; }
Copy link
Contributor

@AlekseyTs AlekseyTs May 16, 2022

Choose a reason for hiding this comment

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

Consider adding a test where this is a pointer and the other field is object. #Closed

Copy link
Contributor

Choose a reason for hiding this comment

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

And flipping the types in the other struct too.

Copy link
Member Author

Choose a reason for hiding this comment

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

The new test is resulting in extra binding. I haven't yet investigated why this is the case.

Copy link
Member

Choose a reason for hiding this comment

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

It looks like the extra binding comes from the StartPropertyType phase. For field symbols, the constraints check was moved to the AfterAccessorBindingChecks call, but in property symbols constraint checks occur as part of binding the property type (SourcePropertySymbolBase.cs:1658 in this branch).

Copy link
Member Author

@Youssef1313 Youssef1313 May 19, 2022

Choose a reason for hiding this comment

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

There is no longer extra binding here. It's fixed in last few commits, but not sure the approach is good.

@AlekseyTs
Copy link
Contributor

Done with review pass (commit 4)

@Youssef1313
Copy link
Member Author

        _ = BackingField?.GetAttributes();

Are we doing the same for the field keyword somewhere?

Refers to: src/Compilers/CSharp/Portable/Symbols/Source/SourcePropertySymbolBase.cs:1263 in 1d040e5. [](commit_id = 1d040e5, deletion_comment = False)

Not yet. A test for this will be related to applying [field: ] on the property. A basic test would be adding [field: My] where MyAttribute doesn't have AttributeTargets.Field

Currently [field: ] isn't supported at all and has a prototype comment in AllowFieldAttributeTarget. Do you want me to handle it in this PR? (The PR is small enough for now, but I don't know if you will feel comfortable handling multiple things in a single PR. Let me know)

@333fred 333fred self-assigned this May 16, 2022
@AlekseyTs
Copy link
Contributor

Do you want me to handle it in this PR?

No.


In reply to: 1128044671

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.

Done review pass (commit 6)

@Youssef1313
Copy link
Member Author

Youssef1313 commented May 17, 2022

@333fred @AlekseyTs I don't quite understand why the used assemblies test fail, and what's the visible user issue is. Are you able to help?

I'm not sure if it's a case where we can safely use NoUsedAssembliesValidation. I attempted to fix the test in a920eab, but I don't think it's a reasonable change.

@Youssef1313
Copy link
Member Author

Ok it looks like the last two commits are breaking things badly. The change wasn't reasonable anyway 😄

@AlekseyTs @333fred Any suggestions?

// This check prevents redundant ManagedAddr diagnostics on the underlying pointer field of a fixed-size buffer
if (!IsFixedSizeBuffer)
var type = Type;
if (type.Kind != SymbolKind.PointerType && !IsFixedSizeBuffer)
Copy link
Contributor

@AlekseyTs AlekseyTs May 20, 2022

Choose a reason for hiding this comment

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

if (type.Kind != SymbolKind.PointerType && !IsFixedSizeBuffer)

It is not obvious why do we still want to perform the check here under this condition? #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.

Which check? IsFixedSizeBuffer? Given the existing code comment, it shouldn't be necessary here. But my thought was to keep it for two reasons:

  1. Simply making sure we align with the existing behavior (but removing shouldn't affect anything given the comment)
  2. The check is very light, it's just (Modifiers & DeclarationModifiers.Fixed) != 0, so we avoid the need to do more work with this small check.

Let me know if you prefer not checking it here.

Copy link
Contributor

Choose a reason for hiding this comment

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

It is not obvious why do we still want to perform the check here under this condition?

Which check?

Sorry for the confusion. I was referring to the Type.CheckAllConstraints that is duplicated between the two methods and performed in this method under the referenced condition.

Copy link
Member Author

Choose a reason for hiding this comment

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

@AlekseyTs At some point I had only AfterAccessorBindingChecks, but for some reason I can't understand, there was a test failure in used assemblies tests. I was asking about that in #61310 (comment).

// public S1* P { get => field; }
Diagnostic(ErrorCode.ERR_ManagedAddr, "P").WithArguments("S1").WithLocation(5, 16));

Assert.Equal(1, accessorBindingData.NumberOfPerformedAccessorBinding);
Copy link
Contributor

@AlekseyTs AlekseyTs May 20, 2022

Choose a reason for hiding this comment

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

Assert.Equal(1, accessorBindingData.NumberOfPerformedAccessorBinding);

There is no longer extra binding here. It's fixed in last few commits, but not sure the approach is good.

It looks like the extra binding is still here. #Closed

Copy link
Member Author

@Youssef1313 Youssef1313 May 21, 2022

Choose a reason for hiding this comment

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

I think it's because I'm delaying CheckAllConstraints call for pointer types in fields only.

I'll need to do special case too many other symbols using one of these approaches:

  • current approach (meaning updating the code in symbols and also special case them in MethodCompiler)
  • updating code in symbols but get back to the virtual AfterAccessorBindingChecks that you requested to revert. The reason it was reverted is we cared only about limited types of symbols, which will no longer be the case now. (my personal preference is using this approach)

Do you like any of these approaches? Is there a completely different approach you'd like me to follow?

Copy link
Member Author

Choose a reason for hiding this comment

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

updating code in symbols but get back to the virtual AfterAccessorBindingChecks that you requested to revert. The reason it was reverted is we cared only about limited types of symbols, which will no longer be the case now.

I'm now using this approach. @AlekseyTs Let me know what do you think. Thanks!

@AlekseyTs
Copy link
Contributor

Done with review pass (commit 13)

Comment on lines 245 to 255
var typeParameters = member switch
{
MethodSymbol m => m.TypeParameters,
NamedTypeSymbol nt => nt.TypeParameters,
_ => ImmutableArray<TypeParameterSymbol>.Empty,
};

foreach (var typeParameter in typeParameters)
{
(typeParameter as SourceTypeParameterSymbolBase)?.AfterAccessorBindingChecks();
}
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'm not much confident about this.

Copy link
Member Author

Choose a reason for hiding this comment

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

It looks like PartialMethodWithArgumentConstraint is now flaky. 😕
@AlekseyTs @333fred Any suggestion on how to correctly avoid extra binding for type parameters constraints checks, and why the current approach is flaky?

@Youssef1313
Copy link
Member Author

@333fred Reverted some changes per our conversation. I'll take another look once required members feature is merged.

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 16). We should have the required members branch merged to main later this week, and when you're done with exams we can look at using the new phase in that branch to address the extra bindings from type constraint checking.

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 16)

@AlekseyTs AlekseyTs merged commit b04c5c3 into dotnet:features/semi-auto-props May 24, 2022
@Youssef1313 Youssef1313 deleted the refactor branch May 24, 2022 13:17
@AlekseyTs
Copy link
Contributor

@Youssef1313 Thanks for the contribution!

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