I noticed in Xcode14b1, if I have a C++ method named
GetValue() that it cannot be found by any Swift code trying to use that object. Renaming the method to any other name works fine. Is there something special about that name that's hardcoded?
Also this only seems to fail with b1, it doesn't fail if I install the latest 5.7-dev toolchain (from June 13), or with any other swift version previously. That implies there might be a set of C++ interop patches applied as part of Xcode releases. Is that true?
Should I bother filing a bug?
Saleem pointed out that I can use
.value in Swift to call the
GetValue() method, and that compiles. So that's a....workaround... but it seems like this should be either documented, or it's just a bug that snuck out with b1. We don't have b2 approved yet for use, I'll try that when we do.
This isn't an issue with b2. Nothing to see here!
I think @zoecarver and company have done work to specifically handle C++
.getFoo() getters as Swift computed property getters to be more ergonomic with Swift. Do you think that maybe both
.foo should be materialized here (ie '.getValue()' and
.value) instead of just the property?
Both are available, it was just strange that only
GetValue() was an error; no other naming of
Get* was a problem.
Ahh, can you do an IR dump with swift-ide-test? It is possible the GetValue is marked unavailable (with the available attributes) but still exists.
That is odd. I would be happy to look into it, especially if you have a reproducer. But if it's been fixed already, it might be hard (and not worth the time). We added a "feature" to map getters and setters (i.e.,
GetValue) into computed properties, but those shouldn't have replaced the methods. Anyway, it turns out that implementation had quite a few bugs, so we ended up putting it behind a another experimental feature flag. I suspect this is what resolved the issue. Off the top of my head, I don't know what Xcode version has what commits, though.
We have a test case that continues to use
GetValue and not the computed property, so if this regresses again, we'll know.
For now I guess just keep fixing bugs behind the other flag. Thanks! :-)
Ok, update: We are still seeing this with
-whole-module-optimization enabled in Xcode14b2. We do not see it without this flag.
Any ideas why this would affect C++ interop?