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

Don't find hidden property instead of the hiding property #1963

Merged
merged 2 commits into from
Sep 4, 2024

Conversation

mspertus
Copy link
Contributor

@mspertus mspertus commented Sep 4, 2024

resolves #1962

When TypeResolver:TryFindMemberAccessor resolves a property, it might find one that was hidden where the non-hidden one would normally be found by C++ member access.

For example, when you access the A member from JavaScript, you may get the hidden one (I say "may" because Type:GetProperties does not specify an order in a number of versions of .NET supported by jint).

class Foo
{
    public int A {get;set;}
    public string B {get;set;}
}

class Bar :  Foo
{
	public new float A { get; set; }
}

(This dotnet fiddle shows that both A elements are iterated by GetProperties even though if b is a Bar, b.A unambiguously refers to Bar:A)

This change ensures that in the case where a property in a derived class hides another, the derived one is resolved to.

When `TypeResolver:TryFindMemberAccessor` resolves a property, it might find one that was hidden where the non-hidden one would normally be found by C++ member access.

For example, when you access the `A` member from JavaScript, you may get the hidden one (I say "may" because `Type:GetProperties` does not specify an order in a number of versions of .NET supported by jint).

```
class Foo
{
    public int A {get;set;}
    public string B {get;set;}
}

class Bar :  Foo
{
	public new float A { get; set; }
}
```

([This dotnet fiddle](http://dotnetfiddle.net/NQRXIJ) shows that both `A` elements are iterated by `GetProperties` even though if `b` is a `Bar`, `b.A` unambiguously refers to `Bar:A`)

This change ensures that in the case where a property in a derived class hides another, the derived one is resolved to.
Copy link
Collaborator

@lahma lahma left a comment

Choose a reason for hiding this comment

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

Thank you for the PR, can you also add a test case ensuring this works as expected and won't break later on by accident.

@mspertus
Copy link
Contributor Author

mspertus commented Sep 4, 2024

Thank you for the PR, can you also add a test case ensuring this works as expected and won't break later on by accident.

Thanks, Lahma. I've added a test and confirmed that it fails without the PR (dotnet462 windows) and passes with it.

@mspertus mspertus requested a review from lahma September 4, 2024 18:18
Copy link
Collaborator

@lahma lahma left a comment

Choose a reason for hiding this comment

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

Looking good, thank you!

@lahma lahma merged commit ca8a653 into sebastienros:main Sep 4, 2024
3 checks passed
@mspertus
Copy link
Contributor Author

mspertus commented Sep 4, 2024

Thanks, @lahma!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TypeResolver should resolve to non-hidden property over property it hides
2 participants