Define static xxxExp::emplace member function#9269
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#9269" |
| emplaceExp!(IntegerExp)(pue, loc, value, type); | ||
| } | ||
|
|
||
| static void emplacei(UnionExp* pue, Loc loc, int value, Type type) |
There was a problem hiding this comment.
What's the point of this overload? Line 1713 can handle it.
There was a problem hiding this comment.
I'd send that question back to you, as I think you introduced createi, but I've yet to see any users of that overload.
I'm all for removing it.
There was a problem hiding this comment.
And infact, osx64 builds are still failing.
Undefined symbols for architecture x86_64:
"IntegerExp::emplace(UnionExp*, Loc, unsigned long, Type*)", referenced from:
test_emplace() in cxxfrontend.o
There was a problem hiding this comment.
As far as I can see, DMD (at least 2.084.0) mangles dinteger_t correctly, as m (on macOS 64bit). But DMD 2.079.0 mangles dinteger_t as y, which is not correct.
There was a problem hiding this comment.
I'm all for removing it.
Yank it.
For new()'ing expressions without allocating memory. These should be marked `@nogc`, but cannot as none of the Expression AST constructors themselves are `@nogc` either.
ibuclaw
force-pushed
the
staticemplace
branch
from
43d7d5a to
10d0056
Compare
|
Keeping emplacei and createi for the benefit of dmd/osx64. |
wilzbach
left a comment
wilzbach
left a comment
There was a problem hiding this comment.
Looks like this is good to go?
6 participants
For new()'ing expressions without allocating memory.
These should be marked
@nogc, but cannot as none of the Expression AST constructors themselves are@nogceither.