diff options
author | Atsushi Kanamori <AtsushiKan@users.noreply.github.com> | 2017-05-22 07:52:23 +0300 |
---|---|---|
committer | Atsushi Kanamori <AtsushiKan@users.noreply.github.com> | 2017-05-22 17:48:39 +0300 |
commit | e391acfbb7fb440f4b5469623f33a4b5d23be369 (patch) | |
tree | c930820487b7d81feabc070ec680cbf1e410d364 /src | |
parent | b6cf2ac7fd726012ed54924fc18d28369920aec1 (diff) |
Implement HasSameMetadataDefinitionAs() on CoreCLR (dotnet/coreclr#11774)
This api was approved here:
https://github.com/dotnet/corefx/issues/5884
and is a necessary step to fixing the System.Dynamic.Runtime.Tests
failure:
https://github.com/dotnet/corefx/issues/19895
which is caused by Microsoft.CSharp trying to do the impossible
and emulate this api without GetMetadataToken() support.
This approach opts for the most straightforward and efficient
implementation without any special-casing for weird situations
(this is also what Microsoft.CSharp implements today as
well as what someone else trying to trampoline members
across generic instantaitions is like to do.)
This results in the following behavior for these
corner cases. With the possible exception of #3,
I think they are tolerable enough to accept and codify:
1. "other" implemented by an entirely different Reflection
provider than "this".
Behavior:
returns false without invoking any methods on the
"other" Member.
To change it to throw an ArgumentException would
mean extra cast checks against the 6 possible
Runtime types (or having said RuntimeTypes implement
a sentinel interface.)
Given that HasSameMetadataDefinitionAs() is a
"looser cousin of Equals()" and "Equals()"
doesn't throw for objects from a different universe,
this seems reasonable.
2. Arrays, ByRefs, Pointers and Types from GetTypeFromCLSID()
Behavior:
Arrays, ByRefs, Pointers all return token 0x0600000
and so they'll return "true" wrt to each other (provided
both types are implemented by the same provider.)
CLSID types all return the typedef of __ComObject
so they'll return "true" wrt to each other.
The constructor exposed by CLSID types all return
the typedef of some constructor on __ComObject so
they'll return "true" wrt to each other.
I do not think these are interesting cases that merit
special handling. These types will never appear
in an enumeration of the members of a type. (The
fact that Reflection surfaces them in objects
that are assignable to MemberInfo is a structural
flaw in Reflection's object model.)
3. Synthesized constructors and methods on array types.
Behavior:
These methods all return 0x06000000 as a token
so the constructors will all compare true wrt
each other, and likewise with the methods.
This is a bit crummy though it's not clear
what the "right" policy should look like.
I could be persuaded to throw NotSupported
for these, to leave the possibility open
for a better story later. On the other hand,
I wouldn't demand it either.
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Diffstat (limited to 'src')
-rw-r--r-- | src/System.Private.CoreLib/shared/System/Reflection/MemberInfo.cs | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/System.Private.CoreLib/shared/System/Reflection/MemberInfo.cs b/src/System.Private.CoreLib/shared/System/Reflection/MemberInfo.cs index 1275cc15a..d8a745863 100644 --- a/src/System.Private.CoreLib/shared/System/Reflection/MemberInfo.cs +++ b/src/System.Private.CoreLib/shared/System/Reflection/MemberInfo.cs @@ -30,6 +30,8 @@ namespace System.Reflection } } + public virtual bool HasSameMetadataDefinitionAs(MemberInfo other) { throw NotImplemented.ByDesign; } + public abstract bool IsDefined(Type attributeType, bool inherit); public abstract object[] GetCustomAttributes(bool inherit); public abstract object[] GetCustomAttributes(Type attributeType, bool inherit); |