[Issue 9631] Error message not using fully qualified name when appropriate.
https://issues.dlang.org/show_bug.cgi?id=9631 Andreas Reischuck changed: What|Removed |Added CC||arbm...@gmail.com --- Comment #11 from Andreas Reischuck --- I tried to tackle this issue at DConf Hackathon. The issue is not totally trivial. Fully qualifying all types in error messages leads to unreadable error messages. Imagine a function with 5 arguments, where each argument is fully qualified. The good solution would be to detect that the error message is ambiguous and only then fall back to fully qualified types. To do this each error has to be inspected separately. Some are more complicated, as types of expressions and arguments are generated independently right now. I suggest to split this issue and create issues for all the situations types are reported to be ambiguous and tackle them one by one. Solving them all at once is quite an endeavor. --
[Issue 17353] is expression type specialization matching strips const
https://issues.dlang.org/show_bug.cgi?id=17353 Nemanja Boric <4bur...@gmail.com> changed: What|Removed |Added CC||4bur...@gmail.com --
[Issue 14402] std.conv.emplace segfaults for nested types
https://issues.dlang.org/show_bug.cgi?id=14402 Nick Treleaven changed: What|Removed |Added Keywords|ice |accepts-invalid CC||n...@geany.org Assignee|nob...@puremagic.com|n...@geany.org Summary|std.conv.emplace segfaults |std.conv.emplace segfaults |for nested class|for nested types --- Comment #3 from Nick Treleaven --- (In reply to Matt Kline from comment #1) > Can we, via template magic or something similar, issue a > similar error when trying to emplace one? I think so, I'm working on a PR. Basically the initializer args have to contain a type that has a usable context pointer. The remaining case is: S s; emplace(&s, S.init); In solving that, I think disallowing rvalue initializers is too strict (as they could have a valid context pointer). Perhaps this can be detected at runtime instead. --
[Issue 9631] Error message not using fully qualified name when appropriate.
https://issues.dlang.org/show_bug.cgi?id=9631 --- Comment #12 from Adam D. Ruppe --- > Fully qualifying all types in error messages leads to unreadable error > messages. I would say if the compiler ever sees `if(t1.toChars == t2.toChars) print toPrettyChars instead`. But there's another option too just output the unreadable error messages on a compiler switch and let external programs like IDEs filter them. The switch could be `-v`, though I still actually really want to see XML error messages, they could list soo much info for ides or external filters. --
[Issue 17361] latest windows 10 insider preview and dmd no longer runs.
https://issues.dlang.org/show_bug.cgi?id=17361 --- Comment #4 from steven kladitis --- just updated to another level of Windows Insider and still DMD does not run. I send to Microsoft. --
[Issue 14402] std.conv.emplace segfaults for nested types
https://issues.dlang.org/show_bug.cgi?id=14402 --- Comment #4 from Nick Treleaven --- https://github.com/dlang/phobos/pull/5379 --
[Issue 17383] New: ICE ddmd/backend/cgxmm.c 930
https://issues.dlang.org/show_bug.cgi?id=17383 Issue ID: 17383 Summary: ICE ddmd/backend/cgxmm.c 930 Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: radu.raca...@gmail.com When building a fairly complex project in release mode under Linux x64 I get the error: Internal error: ddmd/backend/cgxmm.c 930 dmd failed with exit code 1. I can reproduce this error in 2.0.73 and 2.0.74. The compiler used: DMD64 D Compiler v2.074.0 Copyright (c) 1999-2017 by Digital Mars written by Walter Bright --
[Issue 17351] Static const array can't be evaluated at compile time when passed as ref argument
https://issues.dlang.org/show_bug.cgi?id=17351 Mathias Lang changed: What|Removed |Added CC||mathias.l...@sociomantic.co ||m --
[Issue 17384] New: LDC x64 linker error in VS2017
https://issues.dlang.org/show_bug.cgi?id=17384 Issue ID: 17384 Summary: LDC x64 linker error in VS2017 Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: thomas.hedst...@mail.com Created attachment 1646 --> https://issues.dlang.org/attachment.cgi?id=1646&action=edit Not working project Building console app "Hello World" generated from D project templates for target LDC x64 (release or debug) results in linker error: "LINK : fatal error LNK1171: unable to load mspdb140.dll (error code: 126) Error: P:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64\link.exe failed with status: 1171" Tested LDC 1.2.0 and 1.3.0-beta1 VS2017 Community VisualD-v0.44.2 DMD x86,x64 and LDC x86 all compiles. A minimal patch of the build .cmd file indicates that the variable "VSINSTALLDIR" is the cause. Changing "set VSINSTALLDIR=P:\Program Files (x86)\Microsoft Visual Studio\2017\Community\" to empty (or removing it) make it work. "set VSINSTALLDIR=" (The original path exists and seems correct though) --
[Issue 17384] LDC x64 linker error in VS2017
https://issues.dlang.org/show_bug.cgi?id=17384 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from ki...@gmx.net --- The problem is with PATH. The mspdb* DLLs seem to be available for the 2 native linkers (x86 => x86, x64 => x64) only, so for 64-bit targets, it should be `...\bin\HostX64\x64` (the linker being able to use > 3 GB memory being a nice side effect). The WinSDK dir for PATH should most likely also be x64 instead of the current x86 one. [By clearing VSINSTALLDIR, LDC takes care of setting up the environment and that's why it works (1.3 at least, 1.2 doesn't support VS 2017).] --
[Issue 17385] New: Too much commands
https://issues.dlang.org/show_bug.cgi?id=17385 Issue ID: 17385 Summary: Too much commands Product: D Version: D2 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: serafim...@yandex.ru https://goo.gl/WPlPB8 Why not: int example.square(ref int) movDWORD PTR [rdi],0xb xoreax,eax ret ??? We can save 17 bytes. It's 68% of all the procedure binary... What's wrong? --
[Issue 17385] Too much commands
https://issues.dlang.org/show_bug.cgi?id=17385 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from ag0ae...@gmail.com --- (In reply to Serafimati from comment #0) > https://goo.gl/WPlPB8 [...] > We can save 17 bytes. It's 68% of all the procedure binary... What's wrong? You forgot `-O`. --
[Issue 17375] colliding modules detected with binutils 2.28 linker and shared libraries
https://issues.dlang.org/show_bug.cgi?id=17375 Martin Nowak changed: What|Removed |Added Summary|copy relocated ModuleInfos |colliding modules detected |end up getting detected as |with binutils 2.28 linker |duplicates |and shared libraries Severity|enhancement |critical --
[Issue 17375] colliding modules detected with binutils 2.28 linker and shared libraries
https://issues.dlang.org/show_bug.cgi?id=17375 --- Comment #3 from Martin Nowak --- Also see https://sourceware.org/bugzilla/show_bug.cgi?id=20995 and http://sourceware-org.1504.n7.nabble.com/dynrelro-section-for-read-only-dynamic-symbols-copied-into-executable-td429858.html for more info on the binutils change. As a workaround, also compile the executable with -fPIC (PIE). This will avoid the necessity for copy relocation. We made PIE the default in a recent release. --
[Issue 14956] C++ Mangling incompatible with C++11
https://issues.dlang.org/show_bug.cgi?id=14956
Sahmi Soulaïman (سليمان السهمي) changed:
What|Removed |Added
CC||sahmi.soulaim...@gmail.com
--- Comment #10 from Sahmi Soulaïman (سليمان السهمي)
---
I would like to point out that the __cxx11 namespace is not the only problem,
infact there is another non trivial problem is the abi_tag used on functions
that return a std::basic_string.
for exaplme the following function:
```
std::base_string!char func() {}
```
will get the (demangled) name "func[cxx11]()", and there is actually no way of
representing that in D.
--
[Issue 17384] LDC x64 linker error in VS2017
https://issues.dlang.org/show_bug.cgi?id=17384 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #2 from Rainer Schuetze --- kinke's right, the DLL is missing for the cross compilation x86 <-> x64. Visual D uses the x86 folders in case you are working on a 32-bit host OS. There are two workarounds: 1. if you are on 64-bit OS, you can just replace the LDC x64 executable search path $(VCTOOLSINSTALLDIR)bin\HostX86\x64 with $(VCTOOLSINSTALLDIR)bin\HostX64\x64 2. add another folder to the LDC x64 executable search path: $(VSINSTALLDIR)Common7\IDE Visual D doesn't use LDC's automatic detection because it doesn't allow using different versions of VS. --
