@atsushikan could you please take a look?

This does mean, though, that every call to MakeArrayType incurs the cost of that check even if the array type had been previously constructed and memoized.

The custom attribute check only occurs in that corner case of a metadata-carrying type without an EEType. Is there no other way to make that section of the code pay-for-play? Or encode the "this is a byreflike type" in a more direct way within the native metadata format?

(Edit: The fact is IsByRefLike needs to probe custom attributes is in itself something that sticks in my craw as it makes it the only type classifier predicate that reaches code that's both expensive and prone to throwing MissingMetadataExceptions, though I believe the existing reducer behavior would never let that happen.)

Would it be better to do these checks only once you actually try to allocate one of these?

The way these checks are done is pretty ad-hoc. E.g. the check for array of void is done during allocation. I do not think it would do much harm to do the byreflike check there as well.

That would work too. I generally prefer not to put restrictions on constructed Type creation when it's really a runtime restriction on instantiation.

You should probably leave the IsByRef part where it was. It may cause some compat test failures if we're throwing exceptions in a different order from CoreCLR.

I'll assume this still matches CoreCLR's observable validation order (or that you'll make the necessary changes to CoreCLR to match it up.)