Closed angryzor closed 4 months ago
@dotnet-policy-service agree
Thanks so much for looking into this, any chance you could add a test to the test suite?
Thanks so much for looking into this, any chance you could add a test to the test suite?
Sure, here you go! (I hope I added it in the correct place 😅)
We usually have these in https://github.com/mono/CppSharp/blob/main/tests/dotnet/CSharp/CSharp.Tests.cs / https://github.com/mono/CppSharp/blob/main/tests/dotnet/CSharp/CSharp.h which actually does end-to-end testing, but I guess there is nothing inherently wrong with your approach, its just gives a bit less guarantees.
Agh, I had it there first, then saw there was a suite for the passes. Alright, I'll move it over. The strange thing is though, this bug prevents compilation on my machine, so I expected because I didn't undo my fix first. Never mind!TestUncompilableCode
to fail when I added the fixture, but that didn't happen.
So with the test in the new position, the build just fails and the tests can't even be run when the issue is present:
1>------ Build started: Project: CSharp.CSharp, Configuration: Release x64 ------
1>Skipping analyzers to speed up the build. You can execute 'Build' or 'Rebuild' command to run analyzers.
1><...>\CSharp\CSharp.cs(37969,33,37969,72): error CS0534: 'TestOverrideOfPropertyInNamespacedClass' does not implement inherited abstract member 'HasOverridenPropertyInNamespacedClass.Property.get'
1>Done building project "CSharp.CSharp.csproj" -- FAILED.
Is that acceptable?
I think so, there seems to be some delay in running the macOS CI, but looks good otherwise.
The mac CI is still not running, but since its already passing on other platforms, I will just merge it. Again, thanks for the fix.
The mac CI is still not running, but since its already passing on other platforms, I will just merge it. Again, thanks for the fix.
No problem!
See #1283 .
GetterSetterToPropertyPass
currently fails on the following code:Resulting output
The namespace is important. If
Bar
is declared inside the same namespace the bug is not triggered. However, my original code where I encountered this bug did have both classes in the same namespace, though they were in different header files.The bug occurs when it tries to determine whether the property overrides a base property here.
When
Bar
is outside the namespace,Bar
gets processed beforeDorld
, soDorld
doesn't have the property created yet. The check fails and the property is not created onBar
. The property is then later created onDorld
when the pass finally visitsDorld
.When instead
Bar
is inside the namespace,Dorld
is visited first and the code continues as expected.Fixed by setting the
VisitFlags.ClassBases
flag on the pass.