You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is that we (correctly) detect them as being internal nested function, but the frontends appends some std.range templates to vibe.concurrency.core instead of vibe.data.bson, making compilation fail (as the internal function definitions are renamed during bitcode linking the two modules together).
I think the way to go is just to disable the internalizing feature as long as the related logic in the frontend isn't rock-solid.
The text was updated successfully, but these errors were encountered:
This works around linking problems such as vibe-d/vibe.d#338,
caused by the frontend appending template instances to the wrong
module.
GitHub: Fixesldc-developers#558.
Trying to build a simple vibe.d application with LDC yields the following undefined symbols (see e.g. vibe-d/vibe.d#388):
_D4vibe4data4bson14BsonSerializer25writeCompositeEntryHeaderMFE4vibe4data4bson4Bson4TypeZv7Wrapper3putMFaZv
_D4vibe4data4bson14BsonSerializer25writeCompositeEntryHeaderMFE4vibe4data4bson4Bson4TypeZv7Wrapper3putMFxAaZv
The issue is that we (correctly) detect them as being internal nested function, but the frontends appends some std.range templates to
vibe.concurrency.core
instead ofvibe.data.bson
, making compilation fail (as the internal function definitions are renamed during bitcode linking the two modules together).I think the way to go is just to disable the internalizing feature as long as the related logic in the frontend isn't rock-solid.
The text was updated successfully, but these errors were encountered: