Skip to content

Fixing crash with ValueTuple alias when VT is missing (#12032), more tests.#12534

Merged
jcouv merged 2 commits into
dotnet:dev15-preview-4from
jcouv:tuple-crash-preview4
Jul 15, 2016
Merged

Fixing crash with ValueTuple alias when VT is missing (#12032), more tests.#12534
jcouv merged 2 commits into
dotnet:dev15-preview-4from
jcouv:tuple-crash-preview4

Conversation

@jcouv
Copy link
Copy Markdown
Member

@jcouv jcouv commented Jul 14, 2016

Fixes #12032 (crash when looking up static members and VT alias is aliased by missing)

Resolves #11302 (no repro, no crash)
Resolves #12082 (no repro, conversion to tuple of dynamic elements works)
Opened #12468 (allow invoking a ref-return var method with workaround)
Adds some tests

@dotnet/roslyn-compiler for review for preview 4.

@VSadov
Copy link
Copy Markdown
Member

VSadov commented Jul 14, 2016

LGTM

@jcouv
Copy link
Copy Markdown
Member Author

jcouv commented Jul 15, 2016

Thanks Vlad.
@dotnet/roslyn-compiler for a second review of this preview 4 bug fix and extra tests.

@khyperia
Copy link
Copy Markdown
Contributor

Are we sure that this is the right place to put the check if it's an error type? Seems a bit weird that if an error type happens to have the name System.ValueTuple with an arity >0, .IsTupleCompatible() returns true.

If that's the intended behavior, sure, but I feel like it's a bit odd that error symbols are sometimes considered to be tuple-compatible. (Not sure what the exact crash was, but there might be other places that depend on the type not being an error when that method returns true)

@jcouv
Copy link
Copy Markdown
Member Author

jcouv commented Jul 15, 2016

@khyperia
Let me first describe the crash: you define an alias for ValueTuple, but don't reference the ValueTuple library. The LookupStaticMember semantic model API will attempt to list static members on this alias (for instance when you invoke completion in your code). What it got (prior to the fix) was a TupleTypeSymbol (which is a NamedTypeSymbol) which wraps an ErrorType.
For error types, the lookup is cut short. But for NamedTypeSymbol (which appear valid), there is inspection of the containing assembly, which is improper in this case (we didn't find ValueTuple in any specific assembly).

So in the case when the ValueTuple type doesn't exist, I think we should not wrap it into a seemingly valid NamedTypeSymbol as we normally do.
You raise a good question: should this check only be during wrapping, or should it be upstream (when considering if the type looks like a tuple-compatible type)?
Looking at the code paths that check for tuple-compatibility, there may not be a big difference (the primary purpose of checking for tuple-compatibility is to wrap). But I think we still want know that the type appears tuple-compatible.

I'll take a note to run that by Aleksey when he is back as well.

public static TypeSymbol TransformToTupleIfCompatible(TypeSymbol target)
{
if (target.IsTupleCompatible())
if (target.IsTupleCompatible() && !target.IsErrorType())
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Should we check if the target is an error type first? Checking for tuple compatibility is slightly more expensive, I think.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Alternatively, should we just fold this into IsTupleCompatible? I can see a solid justification that ErrorTypes are not tuple compatible.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Error checking first makes total sense.
For folding into IsTupleCompatible that is also the question Evan raised. Let me think and discuss further.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I gave the second suggestion a try, and as I feared it had a lot more implications. So I'll just take the first suggestion (error checking first).
Thanks!

@agocke
Copy link
Copy Markdown
Member

agocke commented Jul 15, 2016

Aside from comment, LGTM

@jcouv
Copy link
Copy Markdown
Member Author

jcouv commented Jul 15, 2016

@MattGertz Could you approve for preview 4? This fixes a crash.

@MattGertz
Copy link
Copy Markdown
Contributor

Approved pending successful tests.

@jcouv jcouv merged commit 88e0625 into dotnet:dev15-preview-4 Jul 15, 2016
@jcouv jcouv deleted the tuple-crash-preview4 branch July 15, 2016 20:52
davidwengier added a commit that referenced this pull request Apr 28, 2026
Fixes dotnet/razor#9829
Part of dotnet/razor#8541

When renaming a component in a Razor file we now call Roslyn so that the
component name or namespace is renamed in all C# code in the solution.
With these changes, once #81450
merges, we'll do the same when renaming a component type name from a C#
file, including updating start and end component tags.
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.

6 participants