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

VB symbolic API incorrect for tuple types. #42860

Open
CyrusNajmabadi opened this issue Mar 28, 2020 · 4 comments
Open

VB symbolic API incorrect for tuple types. #42860

CyrusNajmabadi opened this issue Mar 28, 2020 · 4 comments

Comments

@CyrusNajmabadi
Copy link
Member

Given the following code:

imports System

class Test(of T)
    sub Blah(of T)(t as T)
        dim t2 = (a:=t, b:=4) ' this tuple
    end sub
end class

The VB semantic model till produce a type symbol for that tuple like so:

image

However, strangely, that type symbol will have itself as its 'ConstructedFrom'. i.e.:

image

This is due to this logic here in tupletypesymbol.vb

Public Overrides ReadOnly Property ConstructedFrom As NamedTypeSymbol
Get
Return Me
End Get
End Property

This does not match C# behavior. In C#, if we use the corresponding code:

using System;

class Test<T>
{
    void Blah<T>(T t)
    {
        var t2 = (a: t, b: 4); // this tuple
    }
}

We can see the appropriate 'ConstructedFrom' symbol:

image

@CyrusNajmabadi
Copy link
Member Author

Tagging @gafter @jcouv . Not sure what's up with VB here, but it's super weird. Is there a way in VB to tell if a tuple symbol is 'constructed' and what it was constructed from?

@CyrusNajmabadi
Copy link
Member Author

Oh. It's even weirder. In VB .OriginalDefinition returns the constructed type as well.

@gafter
Copy link
Member

gafter commented Mar 30, 2020

I believe @jcouv intends to implement #39370 for VB, which would fix these issues.

@jcouv
Copy link
Member

jcouv commented Mar 30, 2020

@CyrusNajmabadi Just to let you know: at the moment, issue #20648 for VB isn't prioritized.
If the current VB API behavior blocks your work (ie. there is no way to achieve the desired language-independent abstraction) then please let me know. We'll discuss prioritization with Jared.

@jcouv jcouv removed their assignment Feb 11, 2021
@jcouv jcouv added this to the Backlog milestone Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants