Skip to content
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.

Sign up for GitHub

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

Jump to bottom

linker error in algebraic.d / mir.format #63

Open
WebFreak001 opened this issue Sep 26, 2022 · 4 comments
Open

linker error in algebraic.d / mir.format #63

WebFreak001 opened this issue Sep 26, 2022 · 4 comments

Comments

@WebFreak001
Copy link
Contributor

WebFreak001 commented Sep 26, 2022 •
edited
Loading

just encountered this, going to look into what I can do against this right now.

raw linker output:

ld: error: undefined symbol: _D3mir6format__T5printTaTSQy8appender__T12ScopedBufferTaVmi4096ZQyTSQCo9algebraic__T9AlgebraicTSQDq15algebraic_alias4json5Json_ZQBsZQEmFNbMKQElMAxSQFpQDb__TQCuTQCnZQDcZv
>>> referenced by algebraic.d:1600 (../../.dub/packages/mir-core-1.3.6/mir-core/source/mir/algebraic.d:1600)
>>>               .dub/build/executable-debug-linux.posix-x86_64-dmd_v2.100.0-B49EBC01F803B8795B0F6CFF5E924D92/serve-d.o:(_D3mir9algebraic__T9AlgebraicTSQBd15algebraic_alias4json5Json_ZQBs__T12toStringImplTASQDgQDf__TQCyTQCrZQDgTSQEc8appender__T12ScopedBufferTaVmi4096ZQyZQDdMxFNaNbNiNlNfMKQCjZ12__dgliteral2MFZv)
>>> did you mean: _D3mir6format__T5printTaTSQy8appender__T12ScopedBufferTaVmi4096ZQyTSQCo9algebraic__T9AlgebraicTSQDq15algebraic_alias4json5Json_ZQBsZQEmFNbMKQElMKxSQFpQDb__TQCuTQCnZQDcZv
>>> defined in: .dub/build/executable-debug-linux.posix-x86_64-dmd_v2.100.0-B49EBC01F803B8795B0F6CFF5E924D92/serve-d.o

ddemangle:

ld: error: undefined symbol: nothrow void mir.format.print!(char, mir.appender.ScopedBuffer!(char, 4096uL).ScopedBuffer, mir.algebraic.Algebraic!(mir.algebraic_alias.json.Json_).Algebraic).print(scope ref mir.appender.ScopedBuffer!(char, 4096uL).ScopedBuffer, scope const(mir.algebraic.Algebraic!(mir.algebraic_alias.json.Json_).Algebraic)[])
>>> referenced by algebraic.d:1600 (../../.dub/packages/mir-core-1.3.6/mir-core/source/mir/algebraic.d:1600)
>>>               .dub/build/executable-debug-linux.posix-x86_64-dmd_v2.100.0-B49EBC01F803B8795B0F6CFF5E924D92/serve-d.o:(void mir.algebraic.Algebraic!(mir.algebraic_alias.json.Json_).Algebraic.toStringImpl!(mir.algebraic.Algebraic!(mir.algebraic_alias.json.Json_).Algebraic[], mir.appender.ScopedBuffer!(char, 4096uL).ScopedBuffer).toStringImpl(scope ref mir.appender.ScopedBuffer!(char, 4096uL).ScopedBuffer).__dgliteral2())
>>> did you mean: nothrow void mir.format.print!(char, mir.appender.ScopedBuffer!(char, 4096uL).ScopedBuffer, mir.algebraic.Algebraic!(mir.algebraic_alias.json.Json_).Algebraic).print(scope ref mir.appender.ScopedBuffer!(char, 4096uL).ScopedBuffer, scope ref const(mir.algebraic.Algebraic!(mir.algebraic_alias.json.Json_).Algebraic))
>>> defined in: .dub/build/executable-debug-linux.posix-x86_64-dmd_v2.100.0-B49EBC01F803B8795B0F6CFF5E924D92/serve-d.o
collect2: error: ld returned 1 exit status

project + commit: https://github.com/Pure-D/serve-d/tree/a757a32e301fd6fa7be5bdbf8b727066cab5b9e0
@WebFreak001
Copy link
Contributor Author

seems like some issue auto-inferring ref or not across compilation units

@9il
Copy link
Member

9il commented Sep 26, 2022

How it is compiled?

@WebFreak001
Copy link
Contributor Author

just dub build

for my linked code there I was using the code at libmir/mir-ion#22

WebFreak001 added a commit to WebFreak001/mir-core that referenced this issue Sep 27, 2022
@WebFreak001
workaround compiler bug libmir#63
7c67ff3 
Problem was that the user could pass in types that might not compile the same across all compilation units.

This might be related to https://issues.dlang.org/show_bug.cgi?id=23154 but not sure.

The `static if (__traits(compiles, { auto s = to!(immutable(char)[])(trustedGet!T);}))` was failing for me with

```
../../.dub/packages/mir-core-1.3.6/mir-core/source/mir/algebraic.d(1510,58): Error: `pure` function `mir.algebraic.Algebraic!(Json_).Algebraic.toString!().toString` cannot call impure function `mir.conv.to!string.to!(const(Algebraic!(Json_)[])).to`
../../.dub/packages/mir-core-1.3.6/mir-core/source/mir/algebraic.d(1510,58): Error: `pure` function `mir.algebraic.Algebraic!(Json_).Algebraic.toString!().toString` cannot call impure function `mir.conv.to!string.to!(const(U!(Algebraic!(Json_)))).to`
protocol/source/served/lsp/jsonops.d(50,11): Error: template instance `mir.algebraic.Algebraic!(Json_).Algebraic.toString!()` error instantiating
```

As templates already automatically infer their attributes, this shouldn't be a major breaking change. The `__traits(compiles)` rather looked like it would be inserted to check if the custom method can serialize to a string, not to check if it is pure doing so.
@9il
Copy link
Member

9il commented Sep 28, 2022 •
edited
Loading

Please provide a link to the CI log that demonstrates this issue.

9il pushed a commit that referenced this issue Oct 12, 2022
@WebFreak001
workaround compiler bug #63 (#65)
1dd80b9 
Problem was that the user could pass in types that might not compile the same across all compilation units.

This might be related to https://issues.dlang.org/show_bug.cgi?id=23154 but not sure.

The `static if (__traits(compiles, { auto s = to!(immutable(char)[])(trustedGet!T);}))` was failing for me with

```
../../.dub/packages/mir-core-1.3.6/mir-core/source/mir/algebraic.d(1510,58): Error: `pure` function `mir.algebraic.Algebraic!(Json_).Algebraic.toString!().toString` cannot call impure function `mir.conv.to!string.to!(const(Algebraic!(Json_)[])).to`
../../.dub/packages/mir-core-1.3.6/mir-core/source/mir/algebraic.d(1510,58): Error: `pure` function `mir.algebraic.Algebraic!(Json_).Algebraic.toString!().toString` cannot call impure function `mir.conv.to!string.to!(const(U!(Algebraic!(Json_)))).to`
protocol/source/served/lsp/jsonops.d(50,11): Error: template instance `mir.algebraic.Algebraic!(Json_).Algebraic.toString!()` error instantiating
```

As templates already automatically infer their attributes, this shouldn't be a major breaking change. The `__traits(compiles)` rather looked like it would be inserted to check if the custom method can serialize to a string, not to check if it is pure doing so.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@9il @WebFreak001