-
-
Notifications
You must be signed in to change notification settings - Fork 606
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
cppmangle.d: Fix substitution logic in writeBasicType() #9138
Conversation
Thanks for your pull request, @ibuclaw! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + dmd#9138" |
|
Its also only defined in C++11 with all the fun dealing with that entails. |
src/dmd/cppmangle.d
Outdated
if (auto tm = target.cppTypeMangle(t)) | ||
{ | ||
bool builtin = (t.ty == Tvoid || t.ty == Tbool || t.isintegral() || t.isreal()); | ||
writeBasicType(t, tm.toDString(), builtin); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you need to do a strlen, I suggest having target.cppTypeMangle() return a string in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function is implemented in c++, which doesn't know how D strings are passed around.
Can just drop the []
from writeBasicType instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
( Reversing the order (first check target.cppTypeMangle before doing the hardcoded switch) is helpful: backends no longer need to modify dmdfe source to override the hardcoded mangles. Nice. )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how it was originally, but then it got refactored. This is just a partial revert to former behaviour.
I don't see where Tnull is handled in the code. Most (all?) of the new code seems to be a refactoring, I'm not seeing where the fixes are. I'd prefer to see such significant refactoring done separately. Also, the refactoring is doing a lot of replacing single character literals with strings. This looks slightly nicer, but comes at a cost in code bloat and speed. dmd has slowed down over time due to an accumulation of these sorts of things. I wrote the code the original way for speed reasons. |
About performance: to me it looks like the new code is less performant (e.g. always doing a call to target.cppMangle where in most cases it won't be needed), but if mangling of C++ symbols is a measurable performance bottleneck I'd be very happy ;-) (what I mean is: we don't call these functions so many times, and dynamic alloc+resizing of the mangling string is probably the largest perf issue) |
d4f55d4
to
edf25f4
Compare
Tnull is mangled Dn.
This is a refactor. That it fixes two broken mangling cases is a side effect of this change.
Well speed or no, it was still producing bad symbols by assuming that all two character or greater mangles are non-fundamental types. |
0da051d
to
6461f11
Compare
May I reiterate that fixing and refactoring should be different PRs. I can't find the fixes amid the refactorings. I know it's inconvenient for you, but the payoff is worth it, especially since the mangling code has been a prolific source of problems and regressions. |
I want to make sure it isn't. I haven't profiled it in years, but in the past it certainly has been measurable. An awful lot of symbols go through the mangler, although to be fair fewer of them go specifically through the C++ mangler. |
Other than removing the test, I don't see how. By forcing the caller to say whether they are a fundamental type or not just so happens to fix Tnull mangling, because when I looked at it, it turned out to be using writeBasicType inappropriately. |
ae59c7a
to
67fc6c2
Compare
Moved decision from caller of writeBasicType to callee. Unlike the original patch that was questionably slower, this is definitely slower. :-) |
b472d0b
to
19f1dfc
Compare
Specifically fixes nullptr_t and target-specific mangling. Later on, this will also work for char16_t and char32_t as well.
@@ -727,6 +727,19 @@ void test16() | |||
static assert(0); | |||
} | |||
|
|||
/****************************************/ | |||
/+ FIXME: Requires C++11 compiler. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the time has come to segment tests by C++ version.
You can create a separate file, let's say cppa_11.d
, and use:
// EXTRA_CPP_SOURCES: cppa_11.cpp
// CXXFLAGS: -std=c++11
To test C++11-specific behaviors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice idea though it can probably be done as another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should be rushing to merge PRs without any tests in them.
And it's not a large change to do either, moving a bit of code to a new file, so I really don't understand the hurry.
Semaphore fails due to reproducible build differences. |
If only the diffing tool was smarter to actually pinpoint where it went wrong. However, question... Is it diffing host vs. newly built? Or newly built vs. bootstrap? |
(That was more a reminder to me not to bother to look again before merging it, not something that needs to be fixed.)
It would be nice.
Don't know, don't really care. Reproducible build are nice in theory, but we're not building super secure software so it doesn't really matter. |
Well, I ask because the former points to a bug in the CI script (it will fail if you make any ABI fixes), and the latter points to a bug introduced by this PR. :-) |
It happens frequently enough that I've lost count of the number of PRs I've merged that have had a similar issues, probably the tests fault, but as I said, its not a particularly meaningful test. |
I've just pulled the logs from semaphore, extracted all symbols from the diff and compared, and found nothing whatsoever. Maybe what we're seeing is the infamous feature I've heard about where dmd backend has a built-in stopwatch, and will stop optimizing and skip straight to writing object code if it spends too long going through all passes. |
Hence why I ignore that test.
Maybe, all I know is that the SNR on that test is shockingly bad. |
I'd very much appreciate enabling the C++11 tests. |
|
Specifically fixes nullptr_t and target-specific built-in type mangling (correcting patch in #9129) @JohanEngelen.
Later on, this will also work for char16_t and char32_t as well.