Handle interaction of VB with Static Abstract Members in interfaces#56375
Handle interaction of VB with Static Abstract Members in interfaces#56375AlekseyTs merged 2 commits intodotnet:mainfrom
Conversation
| <value>The CallerArgumentExpressionAttribute applied to parameter will have no effect. It is applied with an invalid parameter name.</value> | ||
| </data> | ||
| <data name="ERR_BadAbstractStaticMemberAccess" xml:space="preserve"> | ||
| <value>A static abstract interface member cannot be accessed.</value> |
There was a problem hiding this comment.
Should we use Shared MustInherit here? And same for the abstract in the message below?
I don't think using MustInherit term is appropriate here because the language doesn't have such concept for interface members. I could replace static with shared for consistency though. Would that address the concern?
There was a problem hiding this comment.
Alright, as long as we're consistent between the error messages I'm ok.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
333fred
left a comment
There was a problem hiding this comment.
LGTM (commit 1), with one minor wording comment.
|
@dotnet/roslyn-compiler For the second review. |
|
@dotnet/roslyn-compiler For the second review. |
2 similar comments
|
@dotnet/roslyn-compiler For the second review. |
|
@dotnet/roslyn-compiler For the second review. |
|
@RikkiGibson PTAL |
| System.Console.WriteLine(NameOf(x.E1)) | ||
| ~~~~ | ||
| </expected>) | ||
| AssertNoDiagnostics(comp) |
There was a problem hiding this comment.
Was this just changed incidentally in order to make events within NameOf more consistent with other kinds of member accesses? #Resolved
There was a problem hiding this comment.
Was this just changed incidentally in order to make events within NameOf more consistent with other kinds of member accesses?
This was changed intentionally for the mentioned reason.
No description provided.