Skip to content

Conversation

@t-camaia
Copy link
Contributor

An if statement was added to check whether we should report ERR_ImplBadTupleNames in the method or in the class declaration. Some tests were also updated.

Fixes #20897.

@t-camaia t-camaia requested a review from a team as a code owner January 25, 2018 01:02
@jaredpar
Copy link
Member

@t-camaia can you retarget this PR to dev15.7.x?

@t-camaia t-camaia changed the base branch from features/compiler to dev15.7.x January 25, 2018 02:22
@t-camaia t-camaia changed the base branch from dev15.7.x to features/compiler January 25, 2018 02:25
@t-camaia t-camaia requested review from a team as code owners January 25, 2018 02:41
@t-camaia t-camaia changed the base branch from features/compiler to dev15.7.x January 25, 2018 02:41
}
else
{
diagnostics.Add(ErrorCode.ERR_ImplBadTupleNames, implementingType.Locations[0], implicitImpl, interfaceMember);
Copy link
Contributor

@AlekseyTs AlekseyTs Jan 25, 2018

Choose a reason for hiding this comment

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

implementingType.Locations[0] [](start = 69, length = 29)

I think the location should be the interface reference in the base list, we probably already have a helper that finds it. #Closed

Copy link
Contributor

@AlekseyTs AlekseyTs Jan 25, 2018

Choose a reason for hiding this comment

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

Take a look at the logic around error location in ReportImplicitImplementationMismatchDiagnostics method in this file. See if we can share it with this method. #Closed

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 25, 2018

    private static void ReportImplicitImplementationMatchDiagnostics(Symbol interfaceMember, TypeSymbol implementingType, Symbol implicitImpl, DiagnosticBag diagnostics)

It looks like other errors reported in this function have the same issue, I think we should fix all of them #Closed


Refers to: src/Compilers/CSharp/Portable/Symbols/TypeSymbol.cs:1041 in ba19c27. [](commit_id = ba19c27, deletion_comment = False)

{
// it is ok to implement implicitly with no tuple names, for compatibility with C# 6, but otherwise names should match
diagnostics.Add(ErrorCode.ERR_ImplBadTupleNames, implicitImpl.Locations[0], implicitImpl, interfaceMember);
if (implicitImpl.ContainingType == implementingType)
Copy link
Contributor

@AlekseyTs AlekseyTs Jan 25, 2018

Choose a reason for hiding this comment

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

if (implicitImpl.ContainingType == implementingType) [](start = 16, length = 52)

Rather than adding a branching that pretty much duplicates the code with some minor variation, consider adding a local function that will return the right location based on conditional logic inside it. #Closed

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 25, 2018

Done with review pass (iteration 1) #Closed

@t-camaia
Copy link
Contributor Author

@AlekseyTs I believe the other errors could only happen with explicit implementations, which means they are always being reported in the expected location. Do you have any particular scenario in mind?

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 26, 2018

I believe the other errors could only happen with explicit implementations, which means they are always being reported in the expected location.

The function is named ReportImplicitImplementationMatchDiagnostics I would be surprised if it was reporting errors for an explicit implementation #Closed

{
var @interface = interfaceMember.ContainingType;
SourceMemberContainerTypeSymbol snt = implementingType as SourceMemberContainerTypeSymbol;
return snt.GetImplementsLocation(@interface) ?? implementingType.Locations[0];
Copy link
Contributor

@AlekseyTs AlekseyTs Jan 26, 2018

Choose a reason for hiding this comment

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

snt. [](start = 31, length = 4)

It feels like this access should be conditional because snt can be null. We should fix the other call site as well #Closed

Copy link
Member

Choose a reason for hiding this comment

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

This could be rewritten as return (implementingType as SourceMemberContainerTypeSymbol)?.GetImplementsLocation(@interface) ?? implementingType.Locations[0]

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 26, 2018

Done with review pass (iteration 2) #Closed

}
}

Location GetDiagnosticLocation(Symbol member)
Copy link
Member

Choose a reason for hiding this comment

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

Please mark as private

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's only a local function. I believe it's not possible to mark it with access modifiers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll put it at the beginning of the method to avoid confusion.

}
}

Location GetDiagnosticLocation(Symbol member)
Copy link
Contributor

@AlekseyTs AlekseyTs Jan 29, 2018

Choose a reason for hiding this comment

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

Symbol member [](start = 43, length = 13)

It feels strange that we are passing a member, but not passing implementingType and interfaceMember . Consider either passing all, or neither. #Closed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are only passing a member because WRN_MultipleRuntimeImplementationMatches may be reported in a location different from implicitImpl.

}
}

Location GetDiagnosticLocation(Symbol member)
Copy link
Contributor

@AlekseyTs AlekseyTs Jan 29, 2018

Choose a reason for hiding this comment

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

GetDiagnosticLocation [](start = 21, length = 21)

I think our naming convention for local function requires them to start with small letter, i.e. "getDiagnosticLocation". #Closed

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 29, 2018

                    ReportAnyMismatchedConstraints(interfaceMethod, implementingType, implicitImplMethod, diagnostics);

It looks like we might want to adjust location for errors reported by this function as well. #Closed


Refers to: src/Compilers/CSharp/Portable/Symbols/TypeSymbol.cs:1068 in 179ee37. [](commit_id = 179ee37, deletion_comment = False)

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 29, 2018

Done with review pass (iteration 3) #Closed

else
{
ReportAnyMismatchedConstraints(interfaceMethod, implementingType, implicitImplMethod, diagnostics);
ReportAnyMismatchedConstraints(interfaceMethod, implementingType, implicitImplMethod, getDiagnosticLocation(implicitImpl), diagnostics);
Copy link
Contributor

@AlekseyTs AlekseyTs Jan 30, 2018

Choose a reason for hiding this comment

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

getDiagnosticLocation(implicitImpl) [](start = 110, length = 35)

We should avoid eager calculation of location before we determined that there is any diagnostics to report. We probably should make getDiagnosticLocation a real (non-local) static function and call it inside ReportAnyMismatchedConstraints when location is needed. #Closed

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jan 30, 2018

Done with review pass (iteration 4) #Closed

@mavasani
Copy link
Contributor

@dotnet-bot retest this please

}
}

private static Location GetDiagnosticLocation(Symbol interfaceMember, TypeSymbol implementingType, Symbol member)
Copy link
Contributor

Choose a reason for hiding this comment

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

GetDiagnosticLocation [](start = 32, length = 21)

GetImplicitImplementationDiagnosticLocation?

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 (iteration 5)

@t-camaia t-camaia merged commit ceb656c into dotnet:dev15.7.x Jan 30, 2018
@t-camaia t-camaia deleted the tuple_bug branch January 30, 2018 22:45
@jcouv jcouv added this to the 15.7 milestone Jan 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants