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

Avoid TypeSpec resolution when checking for IsValueType #80842

Merged
merged 2 commits into from
Jan 20, 2023

Conversation

MichalStrehovsky
Copy link
Member

Contributes to #80165.

This creates a much narrower path to get base type of a type that doesn't bring in complete support for token resolution. IsValueType and IsEnum that call into this are very common.

Also includes a test because the scenario where we wouldn't have a type handle is obscure and we probably didn't have any coverage (even for the previous implementation).

(I have one more reflection fix for #80165 and then I'm done touching the reflection stack.)

Cc @dotnet/ilc-contrib

This creates a much narrower path to get base type of a type that doesn't bring in complete support for token resolution. IsValueType and IsEnum that call into this are very common.
@ghost
Copy link

ghost commented Jan 19, 2023

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

Contributes to #80165.

This creates a much narrower path to get base type of a type that doesn't bring in complete support for token resolution. IsValueType and IsEnum that call into this are very common.

Also includes a test because the scenario where we wouldn't have a type handle is obscure and we probably didn't have any coverage (even for the previous implementation).

(I have one more reflection fix for #80165 and then I'm done touching the reflection stack.)

Cc @dotnet/ilc-contrib

Author: MichalStrehovsky
Assignees: -
Labels:

area-NativeAOT-coreclr

Milestone: -

return Type.GetTypeFromHandle(baseTypeHandle);
}

// Metadata fallback. We only care about very limited subset of all possibilities.
Copy link
Member

Choose a reason for hiding this comment

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

Does this handle struct constrains correctly?

Console.WriteLine(typeof(G<>).GetGenericArguments()[0].IsValueType); // Prints true

class G<T> where T:struct { }

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 because generic parameters implement TypeRefDefOrSpecForBaseType as below.

I'll add a dedicated test. We probably have one somewhere, but can't hurt.

internal sealed override QTypeDefRefOrSpec TypeRefDefOrSpecForBaseType
{
get
{
QTypeDefRefOrSpec[] constraints = Constraints;
TypeInfo[] constraintInfos = ConstraintInfos;
for (int i = 0; i < constraints.Length; i++)
{
TypeInfo constraintInfo = constraintInfos[i];
if (constraintInfo.IsInterface)
continue;
return constraints[i];
}
RuntimeNamedTypeInfo objectTypeInfo = typeof(object).CastToRuntimeNamedTypeInfo();
return objectTypeInfo.TypeDefinitionQHandle;
}

// generic types.
static Type GetLimitedBaseType(RuntimeTypeInfo thisType)
{
// If we have a type handle, just use that
Copy link
Member

Choose a reason for hiding this comment

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

I thought that we got rid of the metadata-only types. Do we still need the metadata-only types? How much benefit do they provide? They feel like an obscure case bug-farm.

Copy link
Member Author

Choose a reason for hiding this comment

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

We got rid of the ones that have type handle, but no metadata. We still have those that have metadata but no type handle. The test has one example where we can come up with such thing. There might be more, I'm not sure I know all situations where this can happen. I think it also might happen if we have a reflected on nested type, but the owning type wasn't touched. We need the metadata. We certainly don't need the vtable.

@MichalStrehovsky MichalStrehovsky merged commit 89352bb into dotnet:main Jan 20, 2023
@MichalStrehovsky MichalStrehovsky deleted the basetype branch January 20, 2023 03:56
mdh1418 pushed a commit to mdh1418/runtime that referenced this pull request Jan 24, 2023
This creates a much narrower path to get base type of a type that doesn't bring in complete support for token resolution. IsValueType and IsEnum that call into this are very common.
@ghost ghost locked as resolved and limited conversation to collaborators Feb 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants