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

Update PDB behavior for 'using alias to type', and add EE and PDB tests. #67105

Conversation

CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi commented Feb 28, 2023

Relates to test plan #56323

// We skip alias imports of embedded types to avoid breaking existing code that imports types
// that can't be embedded but doesn't use them anywhere else in the code. not, this is only
// done for named types. Other sorts of type symbols (arrays, etc.), are allowed through.
var typeRef = GetTypeReference((TypeSymbol)target, syntax, moduleBuilder, diagnostics);
usedNamespaces.Add(Cci.UsedNamespaceOrType.CreateType(typeRef, alias));
Copy link
Member Author

Choose a reason for hiding this comment

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

note: there are def open questions on what the right behavior shoudl be here.

First, i'll note that prior to any of my changes here, this code was already potentially problematic wrt to instantiated named types (like List<EmbeddedType>). We would not skip those since List<> itself was not-linked. Unclear if that was desirable or not.

If that is not desirable, this needs to walk the entire symbol (including type arguments) to see if there are any embedded types.

If the above is intentional, and only the top-level construct is checked, then the new code follows the same logic. Namely that as all other types themselves are not-linked, though internally they may have a linked type (for example EmbeddedType[]), then it's ok to translate them along.

So, this code keeps similar semantics as before. We just need to decide if we want those semantics, or if we want to change things such that any usage of an embedded type would prevent translation.

tagging @AlekseyTs in case he has thoughts on this.

@jcouv jcouv self-assigned this Feb 28, 2023
@CyrusNajmabadi CyrusNajmabadi changed the title Add EE tests for 'using alias to type'. Update PDB behavior for 'using alias to type', and add EE and PDB tests. Feb 28, 2023
@CyrusNajmabadi
Copy link
Member Author

@jcouv @cston @dotnet/roslyn-compiler ptal. This is the last work for using alias to type that i would really like to get merged into main. Thanks :)

@CyrusNajmabadi CyrusNajmabadi requested a review from tmat March 6, 2023 17:22
}
}
";
CompileAndVerify(text, options: TestOptions.DebugDll, targetFramework: TargetFramework.NetFramework).VerifyPdb(@"
Copy link
Member

Choose a reason for hiding this comment

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

targetFramework: TargetFramework.NetFramework

nit: Curious, is the TFM needed?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes. otherwise the referenced symbols come from other dlls, and the specific dlls are checked in the test output.

CyrusNajmabadi and others added 2 commits March 6, 2023 12:19
Co-authored-by: Julien Couvreur <jcouv@users.noreply.github.com>
Co-authored-by: Julien Couvreur <jcouv@users.noreply.github.com>
@CyrusNajmabadi
Copy link
Member Author

@tmat ptal.

Copy link
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

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

LGTM Thanks (iteration 5)

@CyrusNajmabadi CyrusNajmabadi merged commit 6d9fe0d into dotnet:features/UsingAliasesTypes Mar 6, 2023
@CyrusNajmabadi CyrusNajmabadi deleted the usingAliasTests branch March 6, 2023 23:59
@jcouv
Copy link
Member

jcouv commented Mar 7, 2023

It looks like this was merged, not squashed

@CyrusNajmabadi
Copy link
Member Author

Sorry. @jaredpar can you guys write a bot/rule that applies this project preference? I'm not sure what to do about it as github never seems to remember the setting, and so the standard (and preferable) behavior of merging PRs ends up happening, even if that's not what C# compiler wants :(

i'm really not sure how else to get this to happen since the alternative is to depend on people, and people are squishy.

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.

4 participants