dotnet/roslyn

VB SemanticModel fails to bind type argument inside cref even though compiler produces no error

Open

#2,197 opened on 2015年4月23日

GitHub で見る
 (0 comments) (0 reactions) (0 assignees)C# (20,414 stars) (4,257 forks)batch import
Area-CompilersBugConcept-APIhelp wanted

説明

The C# compiler (SemanticModel) correctly returns a TypeParameter symbol for the U in <see cref="C{U}"/> in the below example. I can validate this in the syntax visualizer (see below screenshot) and this also works via API (for example if I get symbol for C{U} and inspect its symbol.TypeArguments. capture

For the corresponding case in VB, U does not bind (see below screenshot). If I get symbol for C(Of U) and inspect its symbol.TypeArguments, I get back a ErrorTypeSymbol. capture2

Shouldn't the VB compiler be able to return a valid symbol in the above case (considering that the code didn't produce any errors)? Why do the two compilers behave differently here.

コントリビューターガイド

技術スタック
csharp
領域
tooling
Issue 種別
bug
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
4
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
over 1 week
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
stale
明確さ期待される変更、受け入れ条件、次の手順がどれだけ明確かを示します。
clear
前提条件
C# and VB basicsRoslyn SemanticModelCompiler binding concepts
初心者向け度初回貢献者にどれだけ取り組みやすいかを 1-100 で推定したスコアです。
15
調査方針
Investigate the VB compiler's implementation of cref binding in documentation comments. Compare with the C# compiler's handling in the same area. Look at the SemanticModel methods for resolving type arguments in crefs. Check if the VB compiler has a similar code path for C(Of U) as C# does for C<U>. The issue's screenshots show the difference in the syntax visualizer, so start by examining the VB syntax tree for the cref and see where binding fails. Also search for any existing tests related to cref binding in VB.