Skip to content

typeof(object).GetMember("") does not return an empty array #16010

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.

Sign up for GitHub

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

Jump to bottom
Closed
slozier opened this issue Aug 3, 2019 · 5 comments
Closed

typeof(object).GetMember("") does not return an empty array #16010

slozier opened this issue Aug 3, 2019 · 5 comments
Assignees
@steveisok
Labels
area-BCL: mscorlib regression
Milestone
2019-06 (6.4.xx)

Comments

@slozier
Copy link

slozier commented Aug 3, 2019

Might be caused by the change in #11003?

Steps to Reproduce

typeof(object).GetMember("").Length;

Current Behavior

The array contains .ctor so the Length is 1.

Expected Behavior

The array should be empty?

On which platforms did you notice this

[ ] macOS
[x] Linux
[ ] Windows

Version Used:

Mono JIT compiler version 6.0.0.313 (tarball Sun Jul 14 09:57:59 UTC 2019)
@slozier slozier mentioned this issue Aug 3, 2019
Merged
@marek-safar
Copy link
Member

@slozier is it regression?

/cc @steveisok

@marek-safar marek-safar added this to the 2019-06 (6.4.xx) milestone Aug 5, 2019
@slozier
Copy link
Author

slozier commented Aug 5, 2019

@marek-safar I believe so since our test just started failing in CI recently. I tried with 5.20.1.34 and it returns an empty array. With the latest .NET Framework and .NET Core we also get an empty array.

@steveisok steveisok self-assigned this Aug 5, 2019
@steveisok
Copy link
Contributor

#11003 likely did it.

Reason being, the prefix check falls through to:

https://github.com/mono/mono/blame/93a6bc31511decdf93357e78fb2a1a14bf7c76c1/mcs/class/referencesource/mscorlib/system/rttype.cs#L2389-L2405

And since it's an empty string, that check returns true and it'll think it can pluck from the array the runtime gave it. Which, in this case it's the default constructor method.

@steveisok
Copy link
Contributor

After some more review, looks like I was wrong. I'm not sure how far back this goes.

In this method:

https://github.com/mono/mono/blame/93a6bc31511decdf93357e78fb2a1a14bf7c76c1/mcs/class/referencesource/mscorlib/system/rttype.cs#L2861-L2871

The callers expect null to equal "*". The problem is that we are treating "" the same. I'll have a PR ready in the morning.

steveisok pushed a commit to steveisok/mono that referenced this issue Aug 6, 2019
Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements.
420a722 
mono#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.
@steveisok steveisok mentioned this issue Aug 6, 2019
Merged
monojenkins pushed a commit to monojenkins/mono that referenced this issue Aug 8, 2019
@monojenkins
Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements.
68ed369 
mono#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.
monojenkins pushed a commit to monojenkins/mono that referenced this issue Aug 8, 2019
@monojenkins
Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements.
8232779 
mono#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.
This was referenced Aug 8, 2019
Merged
Merged
akoeplinger pushed a commit that referenced this issue Aug 8, 2019
@steveisok @akoeplinger
Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements. (#…
64ea10f 
…16054)

#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.
akoeplinger pushed a commit that referenced this issue Aug 8, 2019
@monojenkins @akoeplinger
[2019-08] Fixed RuntimeType.GetConstructorCandidates("") to return 0 …
0707345 
…elements. (#16109)

* Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements.

#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.

* Removed unncessary changes

* Unnecessary spaces

* Made the if check a bit more readable

Backport of #16054.
akoeplinger pushed a commit that referenced this issue Aug 9, 2019
@monojenkins @akoeplinger
[2019-06] Fixed RuntimeType.GetConstructorCandidates("") to return 0 …
63d9836 
…elements. (#16108)

* Fixed RuntimeType.GetConstructorCandidates("") to return 0 elements.

#16010

The current behavior for GetConstructorCandidates when the name is null, "",
or "*" is to return the set of constructors for the type. For "", .NET Core and
.NET Framework return 0 elements.  This PR adds a check for "" to match that
behavior.

* Removed unncessary changes

* Unnecessary spaces

* Made the if check a bit more readable
@akoeplinger
Copy link
Member

Fixed by #16054

jonpryor added a commit to dotnet/android that referenced this issue Aug 11, 2019
@jonpryor
Bump to mono/mono@a7919897
8eef35d 
Fixes: mono/mono#16010
Context: mono/mono#15575
@jonpryor jonpryor mentioned this issue Aug 11, 2019
Merged
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Aug 12, 2019
@jonpryor
Bump to mono/mono@a7919897
ddd3669 
Fixes: mono/mono#15261
Fixes: mono/mono#15262
Fixes: mono/mono#15263
Fixes: mono/mono#15307
Fixes: mono/mono#15575
Fixes: mono/mono#16010

Ignores `TimeZoneTest.TestCtors` on Android GMT, as
`TimeZone.CurrentTimeZone.DaylightName` is an empty value.

[w32socket] Translate ELOOP and ENAMETOOLONG
jonpryor added a commit to dotnet/android that referenced this issue Aug 12, 2019
@jonpryor
Bump to mono/mono@a7919897 (#3478)
84c1105 
Changes: mono/mono@893099f...a791989

Fixes: mono/mono#16010
Context: mono/mono#15575
jonpryor added a commit to dotnet/android that referenced this issue Aug 14, 2019
@jonpryor
Bump to mono/mono@a7919897 (#3443)
bb7ffb7 
Changes: mono/mono@761220d...a791989

Fixes: mono/mono#15261
Fixes: mono/mono#15262
Fixes: mono/mono#15263
Fixes: mono/mono#15307
Fixes: mono/mono#15575
Fixes: mono/mono#15751
Fixes: mono/mono#15825
Fixes: mono/mono#15878
Fixes: mono/mono#15887
Fixes: mono/mono#16010

Context: mono/mono#9621
Context: http://build.azdo.io/2927809

Fix `Socket.ConnectAsync(SocketAsyncEventArgs)` behavior

Ignores `TimeZoneTest.TestCtors` on Android GMT, as
`TimeZone.CurrentTimeZone.DaylightName` is an empty value.

[w32socket] Translate ELOOP and ENAMETOOLONG

Additionally, mono cross compilers are now always 64-bit, as are the
LLVM runtimes.  64-bit cross-compilers broke the xamarin-android
build, as it was using a 32-bit `strip` on them, which failed.

Use the correct `strip` utility, and remove the reference to a
Windows 32bit LLVM runtime which no longer exists.

The mono archive also no longer contains any `llvmwin32` content,
so ensure that the correct LLVM runtimes are installed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@steveisok steveisok

Labels
area-BCL: mscorlib regression
Projects
None yet
Milestone
2019-06 (6.4.xx)
Development

No branches or pull requests
4 participants
@marek-safar @steveisok @akoeplinger @slozier
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy