[Issue 18513] Error: module `scripting` is in file 'std/experimental/scripting.d' which cannot be read
https://issues.dlang.org/show_bug.cgi?id=18513 greenify changed: What|Removed |Added Status|NEW |RESOLVED CC||greeen...@gmail.com Resolution|--- |MOVED --- Comment #1 from greenify --- This looks like it's an issue with the cache. Just modify one character and it will work: https://run.dlang.io/is/mBAkPb We should probably reduce the cache to just one day for dmd-nightly. I will close this here as nothing is wrong with Phobos (well in this regard). I opened: https://github.com/dlang-tour/core/issues/684 Also note that it will be renamed to std.experimental.all soon: https://github.com/dlang/phobos/pull/6186 --
[Issue 18515] New: freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default
https://issues.dlang.org/show_bug.cgi?id=18515 Issue ID: 18515 Summary: freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default Product: D Version: D2 Hardware: x86 OS: FreeBSD Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bra...@puremagic.com DMD uses 'gcc' to perform the link step. On freebsd 11 (and likely other earlier versions, unexplored), gcc -m32 fails to link, looking at 64 bit library paths instead. This combination results in freebsd 11 32 non-functional. Either 'clang' or 'cc' work just fine. For the auto-testers, they're currently running with CC set to cc in their environment. That's not particularly acceptable an out of the box experience for users of that platform. IMHO, DMD needs to use 'cc' by default rather than gcc. Without having double checked, I suspect that will work on any relatively modern platform without causing regressions. --
[Issue 18514] New: freebsd 11 with clang fails cpp abi tests
https://issues.dlang.org/show_bug.cgi?id=18514 Issue ID: 18514 Summary: freebsd 11 with clang fails cpp abi tests Product: D Version: D2 Hardware: x86 OS: FreeBSD Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bra...@puremagic.com /home/ec2-user/sandbox/at-client/pull-3047185-FreeBSD_32/dmd/generated/freebsd/release/32/dmd -conf= -m32 -Irunnable -L-lstdc++ -odgenerated/runnable -ofgenerated/runnable/cppa_0 runnable/cppa.d generated/runnable/cppb.cpp.o generated/runnable/cppa_0 core.exception.AssertError@runnable/cppa.d(259): Assertion failure ??:? _d_assertp [0x285a87ae] ??:? ??? [0x8049b00] ??:? pure nothrow ref @nogc @trusted immutable(char) object.__equals!(char, immutable(char)).__equals(char[], immutable(char)[]).at!(immutable(char)).at(immutable(char)[], uint) [0x804b429] ??:? ??? [0x8049b24] ??:? ??? [0x804ab35] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().__lambda1() [0x285ce20a] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x285ce059] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x285ce174] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x285ce059] ??:? _d_run_main [0x285cdfbf] ??:? pure nothrow ref @nogc @trusted immutable(char) object.__equals!(char, immutable(char)).__equals(char[], immutable(char)[]).at!(immutable(char)).at(immutable(char)[], uint) [0x804acab] ??:? ??? [0x8049518] ??:? ??? [0x80493f7] ??:? ??? [0x0] i = 1 j = 2 k = 3 i = 1 j = 2 k = 3 i = 1 j = 2 k = 3 this = 0x288d2000 i = 4 j = 5 k = 6 this = 0x28c1e1f0 D.bar: i = 9 D.bar: j = 10 D.bar: k = 11 F.bar: i = 11 F.bar: j = 12 F.bar: k = 13 == Test failed: expected rc == 0, exited with rc == 1 --
[Issue 18513] New: Error: module `scripting` is in file 'std/experimental/scripting.d' which cannot be read
https://issues.dlang.org/show_bug.cgi?id=18513 Issue ID: 18513 Summary: Error: module `scripting` is in file 'std/experimental/scripting.d' which cannot be read Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: timothee.co...@gmail.com documented unittest fails in https://dlang.org/phobos-prerelease/std_experimental_scripting.html onlineapp.d(3): Error: module `scripting` is in file 'std/experimental/scripting.d' which cannot be read import path[0] = /dlang/dmd-nightly/linux/bin64/../../src/phobos import path[1] = /dlang/dmd-nightly/linux/bin64/../../src/druntime/import --
[Issue 18512] auto-tester fails /usr/local/bin/ld: cannot find -lpthread only on FreeBSD_32
https://issues.dlang.org/show_bug.cgi?id=18512 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m OS|Mac OS X|FreeBSD --
[Issue 18512] New: auto-tester fails /usr/local/bin/ld: cannot find -lpthread only on FreeBSD_32
https://issues.dlang.org/show_bug.cgi?id=18512 Issue ID: 18512 Summary: auto-tester fails /usr/local/bin/ld: cannot find -lpthread only on FreeBSD_32 Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: timothee.co...@gmail.com https://auto-tester.puremagic.com/show-run.ghtml?projectid=14&runid=3047114&isPull=true CC="c++" /home/ec2-user/sandbox/at-client/release-build/install/freebsd/bin32/dmd -of../generated/freebsd/release/32/dmd -m32 -vtls -J../generated/freebsd/release/32 -J../res -L-lstdc++ -version=MARS -w -de -O -release -inline dmd/access.d dmd/aggregate.d dmd/aliasthis.d dmd/apply.d dmd/argtypes.d dmd/arrayop.d dmd/arraytypes.d dmd/astcodegen.d dmd/attrib.d dmd/builtin.d dmd/canthrow.d dmd/cli.d dmd/clone.d dmd/compiler.d dmd/complex.d dmd/cond.d dmd/constfold.d dmd/cppmangle.d dmd/cppmanglewin.d dmd/ctfeexpr.d dmd/dcast.d dmd/dclass.d dmd/declaration.d dmd/delegatize.d dmd/denum.d dmd/dimport.d dmd/dinifile.d dmd/dinterpret.d dmd/dmacro.d dmd/dmangle.d dmd/dmodule.d dmd/doc.d dmd/dscope.d dmd/dstruct.d dmd/dsymbol.d dmd/dsymbolsem.d dmd/dtemplate.d dmd/dversion.d dmd/escape.d dmd/expression.d dmd/expressionsem.d dmd/func.d dmd/hdrgen.d dmd/id.d dmd/impcnvtab.d dmd/imphint.d dmd/init.d dmd/initsem.d dmd/inline.d dmd/inlinecost.d dmd/intrange.d dmd/json.d dmd/lambdacomp.d dmd/lib.d dmd/libelf.d dmd/libmach.d dmd/link.d dmd/mars.d dmd/mtype.d dmd/nogc.d dmd/nspace.d dmd/objc.d dmd/opover.d dmd/optimize.d dmd/parse.d dmd/permissivevisitor.d dmd/sapply.d dmd/templateparamsem.d dmd/sideeffect.d dmd/statement.d dmd/staticassert.d dmd/target.d dmd/typesem.d dmd/traits.d dmd/transitivevisitor.d dmd/parsetimevisitor.d dmd/visitor.d dmd/typinf.d dmd/utils.d dmd/scanelf.d dmd/scanmach.d dmd/statement_rewrite_walker.d dmd/statementsem.d dmd/staticcond.d dmd/safe.d dmd/blockexit.d dmd/printast.d dmd/semantic2.d dmd/semantic3.d dmd/irstate.d dmd/toctype.d dmd/glue.d dmd/gluelayer.d dmd/todt.d dmd/tocsym.d dmd/toir.d dmd/dmsc.d dmd/tocvdebug.d dmd/s2ir.d dmd/toobj.d dmd/e2ir.d dmd/eh.d dmd/iasm.d dmd/objc_glue.d dmd/backend/bcomplex.d dmd/backend/cc.d dmd/backend/cdef.d dmd/backend/cgcv.d dmd/backend/code.d dmd/backend/cv4.d dmd/backend/dt.d dmd/backend/el.d dmd/backend/global.d dmd/backend/obj.d dmd/backend/oper.d dmd/backend/outbuf.d dmd/backend/rtlsym.d dmd/backend/code_x86.d dmd/backend/iasm.d dmd/backend/ty.d dmd/backend/type.d dmd/backend/exh.d dmd/backend/mach.d dmd/backend/md5.d dmd/backend/mscoff.d dmd/backend/dwarf.d dmd/backend/dwarf2.d dmd/backend/xmm.d dmd/tk/dlist.d dmd/root/aav.d dmd/root/man.d dmd/root/response.d dmd/root/speller.d ../generated/freebsd/release/32/newdelete.o ../generated/freebsd/release/32/backend.a ../generated/freebsd/release/32/lexer.a ../generated/freebsd/release/32/cxx-unittest gmake[1]: Leaving directory '/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src' gmake -C src -f posix.mak all gmake[1]: Entering directory '/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src' no cpu specified, assuming X86 posix.mak:123: == Use HOST_DMD instead of HOST_DC == gmake[1]: Nothing to be done for 'all'. gmake[1]: Leaving directory '/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src' gmake INSTALL_DIR=/home/ec2-user/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/../install -C src -f posix.mak install gmake[1]: Entering directory '/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src' no cpu specified, assuming X86 posix.mak:123: == Use HOST_DMD instead of HOST_DC == gmake -C ../docs DMD=/home/ec2-user/sandbox/at-client/release-build/install/freebsd/bin32/dmd build gmake[2]: Entering directory '/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/docs' /home/ec2-user/sandbox/at-client/release-build/install/freebsd/bin32/dmd -I../src -of../generated/freebsd/release/32/gen_man gen_man.d ../src/dmd/cli.d cp man/man1/obj2asm.1 ../generated/docs/man/man1/obj2asm.1 cp man/man1/dumpobj.1 ../generated/docs/man/man1/dumpobj.1 cp man/man5/dmd.conf.5 ../generated/docs/man/man5/dmd.conf.5 /usr/local/bin/ld: skipping incompatible //usr/lib/libpthread.so when searching for -lpthread /usr/local/bin/ld: skipping incompatible //usr/lib/libpthread.a when searching for -lpthread /usr/local/bin/ld: cannot find -lpthread /usr/local/bin/ld: skipping incompatible //usr/lib/libm.so when searching for -lm /usr/local/bin/ld: skipping incompatible //usr/lib/libm.a when searching for -lm /usr/local/bin/ld: cannot find -lm /usr/local/bin/ld: skipping incompatible /usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd11.1/6.4.0/libgcc.a when searching for -lgcc /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when searching for -lgcc /usr/local/bin/ld: cannot find
[Issue 18508] Using statement without effect should error
https://issues.dlang.org/show_bug.cgi?id=18508 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer --- It is supposed to be illegal to use the result of a comma expression. See here: https://dlang.org/spec/expression.html#expression --
[Issue 18511] Using std.range / std.algorithm templates cause big slowdown in compilation time
https://issues.dlang.org/show_bug.cgi?id=18511 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18504] Assert in synchronized crashes with SIGILL on exit
https://issues.dlang.org/show_bug.cgi?id=18504 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18508] Using statement without effect should error
https://issues.dlang.org/show_bug.cgi?id=18508 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #1 from Jonathan M Davis --- I'm not sure what is and isn't supposed to be legal with the comma operator now, but if the issue is that the statement has no effect, then there isn't necessarily a bug here, because f isn't pure. Yes, _we_ can see that f has no effect, but the compiler doesn't look past the signature. Now, I slapped pure on f to see what would happen, and that still doesn't produce an error, so there probably is a bug if your example has pure on f, but as-is, I'm not sure that it actually shows a bug. --
[Issue 17961] std.uni does not compile with -unittest -dip1000
https://issues.dlang.org/show_bug.cgi?id=17961 Carsten Blüggel changed: What|Removed |Added Assignee|chi...@posteo.net |nob...@puremagic.com --
[Issue 18510] [Beta 2.079] lld-link.exe fails to open obj file in subpath
https://issues.dlang.org/show_bug.cgi?id=18510 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #2 from Rainer Schuetze --- https://github.com/dlang/dmd/pull/7946 --
[Issue 17819] static foreach segfaults on __traits(allMembers)
https://issues.dlang.org/show_bug.cgi?id=17819 --- Comment #2 from Jean-Louis Leroy --- Still present in v2.078.3 - it seems that no one is looking into this. --
[Issue 18511] Using std.range / std.algorithm templates cause big slowdown in compilation time
https://issues.dlang.org/show_bug.cgi?id=18511 --- Comment #1 from hst...@quickfur.ath.cx --- Sorry, missed the command for compiling the slow version: time dmd -c -version=slow test.d --
[Issue 18511] New: Using std.range / std.algorithm templates cause big slowdown in compilation time
https://issues.dlang.org/show_bug.cgi?id=18511
Issue ID: 18511
Summary: Using std.range / std.algorithm templates cause big
slowdown in compilation time
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: hst...@quickfur.ath.cx
Code:
--
double dot(double[] a, double[] b) {
version(fast) {
assert(a.length == b.length);
double acc = 0.0;
foreach (i; 0 .. a.length)
acc += a[i] * b[i];
return acc;
}
version (slow) {
import std.range : zip;
import std.algorithm.iteration : fold, map;
return zip(a[], b[])
.map!(x => x[0]*x[1])
.fold!((a, b) => a + b)(0.0);
}
}
--
Compiling with manually-written loop:
--
$ time dmd -c -version=fast test.d
real0m0.021s
user0m0.014s
sys 0m0.007s
--
Compiling with fancy std.algorithm / std.range templates:
--
real0m0.499s
user0m0.444s
sys 0m0.054s
--
Now, I understand that using fancy generic code templates requires more work on
the part of the compiler, so some degree of slowdown in compilation times is to
be expected.
However, this is an *order of magnitude* slowdown in compiling two
functionally-equivalent pieces of code, and very simple code at that. Given
our current fast-fast-fast slogan, I think this is unacceptable.
--
[Issue 18510] [Beta 2.079] lld-link.exe fails to open obj file in subpath
https://issues.dlang.org/show_bug.cgi?id=18510 --- Comment #1 from Rainer Schuetze --- Not automatically appending the ".obj" seems to be an incompatibility with the MS linker. --
[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll
https://issues.dlang.org/show_bug.cgi?id=18509 --- Comment #3 from ki...@gmx.net --- (In reply to Rainer Schuetze from comment #1) > I think we should link lld-link.exe statically against the VC/C++ libraries. I agree; CMake option LLVM_USE_CRT_RELEASE=MT (assuming CMAKE_BUILD_TYPE=Release). > I suspect LLVM does not build with anything before VC2015 because latest C++ > is used. Yep, from https://llvm.org/docs/GettingStartedVS.html: "You will need Visual Studio 2015 or higher, with the latest Update installed." --
[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll
https://issues.dlang.org/show_bug.cgi?id=18509 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #2 from Rainer Schuetze --- https://github.com/dlang/installer/pull/305 --
[Issue 18510] New: [Beta 2.079] lld-link.exe fails to open obj file in subpath
https://issues.dlang.org/show_bug.cgi?id=18510 Issue ID: 18510 Summary: [Beta 2.079] lld-link.exe fails to open obj file in subpath Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: major Priority: P2 Component: installer Assignee: nob...@puremagic.com Reporter: c...@dawg.eu CC: r.sagita...@gmx.de C:\>C:\D\dmd2\windows\bin\dmd.exe -ofdub.exe sub\dub.obj -m32mscoff -v predefs DigitalMars Windows LittleEndian D_Version2 all D_InlineAsm D_InlineAs m_X86 X86 Win32 CRuntime_Microsoft assert D_HardFloat binaryC:\D\dmd2\windows\bin\dmd.exe version v2.079.0-beta.1 configC:\D\dmd2\windows\bin\sc.ini DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos -IC:\D\dmd2\windows\bin\..\..\src\druntime\import C:\D\dmd2\windows\bin\lld-link.exe /NOLOGO "sub\dub" /OUT:"dub.exe" /OPT:NOICF C:\D\dmd2\windows\bin\lld-link.exe: error: could not open sub\dub: no such file or directory C:\D\dmd2\windows\bin\lld-link.exe: warning: /machine is not specified. x64 is assumed error: entry point must be defined Error: linker exited with status 1 Weirdly the .obj suffix is stripped from the command line, might be a leftover from optlink. --
[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll
https://issues.dlang.org/show_bug.cgi?id=18509 --- Comment #1 from Rainer Schuetze --- I think we should link lld-link.exe statically against the VC/C++ libraries. I suspect LLVM does not build with anything before VC2015 because latest C++ is used. I chose VC2010 in the hope that it is already installed on most systems, though plain Windows doesn't seem to have it. The runtimes for VC2015 or later are a bit messy as they rely on the UCRT aswell. It is a bit of a hassle to install these on Win7 or earlier. --
[Issue 18385] [REG 2.079] method cannot be overloaded with another extern(C) method
https://issues.dlang.org/show_bug.cgi?id=18385 Jesse Phillips changed: What|Removed |Added CC||jesse.k.phillip...@gmail.co ||m --- Comment #7 from Jesse Phillips --- So C clearly doesn't support function overloads, but D provides for better type checking and generally expects as much. I think it would be nice to allow D to specify function overloads if the C call is ultimately the same (parameter sizes and such). This way in D a function can be specified to accept pointer types of A, B, and C rather than needing to be a void* as it is defined in C. I think it is similar to marking a parameter const even though it has no meaning to C and isn't actually enforced. This also appears to be how DWT has utilized definitions. I've realized that my upgrade to dxml and DWT for an application has cause my application to not compile on any of the D compilers, so a solution here would be nice or for [18475] to be fixed on 2.078. 18475: https://issues.dlang.org/show_bug.cgi?id=18475 --
[Issue 18509] New: [Beta 2.079] lld-link.exe needs msvcp140.dll
https://issues.dlang.org/show_bug.cgi?id=18509 Issue ID: 18509 Summary: [Beta 2.079] lld-link.exe needs msvcp140.dll Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P2 Component: installer Assignee: nob...@puremagic.com Reporter: c...@dawg.eu CC: r.sagita...@gmx.de While we're installing the VC++ 2010 redisditributable, we've apparently linked lld-link.exe against VC++ 2015 or so. I just deinstalled all MSVC++ redistributables prior to trying the installer with the new MinGW option. Seems like we have a couple of options: - compile lld-link.exe with VC++ 2010 if that still works (could possibly break depending on lld codebase) - use VC++ 2015 redist as C runtime (requires some changes in the mingw build script and possibly the msvcrt stub) (https://github.com/dlang/installer/pull/289) - install both redistributables with the MinGW option - ship msvcp140.dll with lld-link.exe (https://msdn.microsoft.com/en-us/library/dd293574.aspx#Anchor_1) - link lld-link.exe statically against MSVCRT Any opionion? Why was 2010 choosen as redistributable? It feels weird to install such an old C runtime. IIRC there was some point about msvcrt100.dll being preinstalled on all Windows versions, that would be a plus for distributing D apps. But I'm not sure how relevant that is and why the installer requires me to install a redistributable VC++ 2010 regardless. --
[Issue 18508] New: Using statement without effect should error
https://issues.dlang.org/show_bug.cgi?id=18508
Issue ID: 18508
Summary: Using statement without effect should error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: greensunn...@gmail.com
cat << EOF | dmd -c -o- -
int f(int a){ return a; }
void main()
{
int a;
a=f(0),f(1);
assert(a==1);
}
EOF
It already errors for
cat << EOF | dmd -c -o- -
int f(int a){ return a; }
void main()
{
int a;
a=0,1;
assert(a==1);
}
EOF
--
[Issue 11216] Make synchronized statement `nothrow`
https://issues.dlang.org/show_bug.cgi?id=11216 --- Comment #11 from FeepingCreature --- Istm a possible approach would be: * Define SimpleMonitor : Monitor with nothrow * change DMD to use nothrow when locking SimpleMonitors * subclass druntime's Mutex with SimpleMutex : Mutex, SimpleMonitor * use SimpleMutex as the mutex implementation for class monitors Then synchronized(this) should be nothrow without breaking existing code that depends on Mutex/Monitor. It would only break if you were assigning to _monitor, and that's easily fixed by using a separate member. I don't know how to implement this on the DMD side though. --
[Issue 18507] New: Linker errors on FreeBSD related to .data.d_dso_rec
https://issues.dlang.org/show_bug.cgi?id=18507 Issue ID: 18507 Summary: Linker errors on FreeBSD related to .data.d_dso_rec Product: D Version: D2 Hardware: x86_64 OS: FreeBSD Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: issues.dl...@jmdavisprog.com Created attachment 1681 --> https://issues.dlang.org/attachment.cgi?id=1681&action=edit File which reproduces the issue If the attached file is compiled with dmd -main -unittest test.d on x86_64 FreeBSD 11.1 then I get this linker error: /usr/bin/ld: test.o: no group info for section .data.d_dso_rec /usr/bin/ld: test.o: no group info for section .text.d_dso_init /usr/bin/ld: test.o: no group info for section .dtors.d_dso_dtor /usr/bin/ld: test.o: no group info for section .ctors.d_dso_ctor I have no idea if x86 has the same problem or not, but the problem does not seem to occur on 64-bit Linux. So, the problem seems to be FreeBSD-specific. I have no clue whether older versions of FreeBSD have the problem or not, but in theory, we're only supporting the latest version of FreeBSD, which is currently 11.1. I'm sorry that the example code is as disgusting-looking as it is, but it's the result of several runs of dustmite on one of my projects, and the linker errors seem to happen only under some fairly specific circumstances, since it doesn't take much to tweak the code to make the problem go away - though I did manage to get the actual project to into a state where it was very hard to make the problem go away. Fortunately for the project, after some serious refactoring to remove some templated stuff that didn't turn out to be necessary, the problem went away, so this isn't currently blocking my project, but we really shouldn't be getting linker errors like this - especially when other platforms have no problem with the exact same code. --
[Issue 11216] Make synchronized statement `nothrow`
https://issues.dlang.org/show_bug.cgi?id=11216 FeepingCreature changed: What|Removed |Added CC||default_357-l...@yahoo.de --- Comment #10 from FeepingCreature --- Still an issue in 2018. --
[Issue 18503] Confusing error message for erroneous postblit
https://issues.dlang.org/show_bug.cgi?id=18503 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18503] Confusing error message for erroneous postblit
https://issues.dlang.org/show_bug.cgi?id=18503 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/60e3422667a46b31f6d9d1cbcbe81479cfa71c6f Fix Issue 18503 - Confusing error message for erroneous postblit https://github.com/dlang/dmd/commit/75b460e65ee1c5c3506ff676793f20cb999da2ce Merge pull request #7943 from RazvanN7/Issue_18503 [Trivial review] Fix Issue 18503 - Confusing error message for erroneous postblit --
[Issue 6605] Add switch to enable setting library search paths via command line
https://issues.dlang.org/show_bug.cgi?id=6605 Diederik changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18506 --
[Issue 18506] pragma(lib, xxx) can cause issues when library is to be found outside OS standard library search path
https://issues.dlang.org/show_bug.cgi?id=18506 Diederik changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=6605 --
[Issue 18506] pragma(lib, xxx) can cause issues when library is to be found outside OS standard library search path
https://issues.dlang.org/show_bug.cgi?id=18506 Diederik changed: What|Removed |Added URL||https://github.com/dlang/to ||ols/pull/316 See Also||https://github.com/dlang/to ||ols/pull/316 --
[Issue 6605] Add switch to enable setting library search paths via command line
https://issues.dlang.org/show_bug.cgi?id=6605 Diederik changed: What|Removed |Added CC||dkgr...@talon.nl --
[Issue 18506] New: pragma(lib, xxx) can cause issues when library is to be found outside OS standard library search path
https://issues.dlang.org/show_bug.cgi?id=18506 Issue ID: 18506 Summary: pragma(lib, xxx) can cause issues when library is to be found outside OS standard library search path Product: D Version: D2 Hardware: All OS: FreeBSD Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: dkgr...@talon.nl standard/conventional - On BSD the /usr/local/lib directory is a conventional path to put libraries, it is however not a default path. ie: It is not searched by default when linking binaries. It normally needs to be specified manually (via LDFLAGS) when linking. However It is one of the default search paths when loading dynamic libraties (ie: ld.so) (which is a little strange but it is the way it is). Potential resolution: If you guys think we should re-use the same paths used for dynamic loading, we could parse the ldconfig settings, (via /usr/include/aout-hints.h and /usr/include/elf-hints.h), so that we can add these paths to search for -llibname / pragma(lib) during linking. Note: on bsd ldconfig uses a binary file (ie: /var/run/ld-elf.so.hints), which needs to be read using the headers mentioned above. This method differs from the way linux does work. Note: There is no way to suppress pragma(lib, "xxx") from the commandline (issue/6605), to get around the issue. Links: https://github.com/dlang/tools/pull/316 https://forum.dlang.org/post/lsqudbuxrnvlbwhlx...@forum.dlang.org --
[Issue 18505] New: delete deprecation message is misleading
https://issues.dlang.org/show_bug.cgi?id=18505 Issue ID: 18505 Summary: delete deprecation message is misleading Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: diagnostic Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com Currently, the dprecation message for delete says: Deprecation: The delete keyword has been deprecated. Use object.destroy() instead. However, this is not complete. In order to fully replace the mechanism of delete, you must call GC.free on the pointer. In many cases, people have used delete and expect the memory to be freed. Telling them that all they have to do is use destroy is not going to satisfy. I suggest (similar to Bearophile's suggestion in issue 9433): use object.destroy (and optionally core.memory.GC.free) instead. There is also this new function (unreleased as of 2.079, but in druntime already): https://dlang.org/phobos-prerelease/core_memory.html#.__delete --
[Issue 9433] Deprecate delete
https://issues.dlang.org/show_bug.cgi?id=9433 --- Comment #16 from Steven Schveighoffer --- *** Issue 11949 has been marked as a duplicate of this issue. *** --
[Issue 11949] Warning and later deprecation message for usage of delete
https://issues.dlang.org/show_bug.cgi?id=11949 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution|--- |DUPLICATE --- Comment #11 from Steven Schveighoffer --- *** This issue has been marked as a duplicate of issue 9433 *** --
[Issue 18504] Assert in synchronized crashes with SIGILL on exit
https://issues.dlang.org/show_bug.cgi?id=18504 --- Comment #1 from FeepingCreature --- Note that this issue appears in a similar form with crashes on GC cleanup of objects if an assert failed in a synchronized(this) invariant block. --
[Issue 18504] New: Assert in synchronized crashes with SIGILL on exit
https://issues.dlang.org/show_bug.cgi?id=18504
Issue ID: 18504
Summary: Assert in synchronized crashes with SIGILL on exit
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Testcase:
void main() { synchronized assert(0); }
Expected: Error printed, program exits with error code.
Actual: Error printed, program exits with Illegal Instruction.
What happens:
In 9327d158d457093f5fc064a844f3400515558112 (emit better code for try-finally
when function does not throw) for v2.078.0, Walter added an optimization that
finally blocks can be handled more efficiently if the function does not throw
exceptions.
AssertError is not an exception.
As a result, the mutex of the synchronized{} block is never unlocked.
On program exit, the runtime tries to clean up mutexes at program end.
(_d_critical_term -> destroyMutex -> pthread_mutex_destroy)
pthread_mutex_destroy errors if the mutex is still locked. This triggers the
assert(0), which shows (in release mode) as a ud2: illegal instruction.
--
[Issue 18503] Confusing error message for erroneous postblit
https://issues.dlang.org/show_bug.cgi?id=18503 --- Comment #1 from RazvanN --- PR : https://github.com/dlang/dmd/pull/7943 --
[Issue 18503] New: Confusing error message for erroneous postblit
https://issues.dlang.org/show_bug.cgi?id=18503
Issue ID: 18503
Summary: Confusing error message for erroneous postblit
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: razvan.nitu1...@gmail.com
This code:
class C
{
this(this) {}
}
issues:
test.d(3): Error: postblit can only be a member of struct/union, not class C
Ok. Let's define a union with a postblit:
union D
{
this(this) {}
}
output:
test.d(8): Error: function `test.D.__postblit` destructors, postblits and
invariants are not allowed in union D
That's odd, you just instructed me that a union can have a postblit! Shame on
you compiler!
Spec: "Unions may not have postblits, destructors, or invariants." [1]
[1] https://dlang.org/spec/struct.html
--
[Issue 15217] overloaded extern(C) function declarations are allowed
https://issues.dlang.org/show_bug.cgi?id=15217 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #2 from Martin Nowak --- This was invented as a tool to deprecate callbacks missing those attributes. There is unfortunately no wildcard to infer function attributes from parameter (callback) attributes, though this use-case comes up frequently (e.g. in interface and class methods besides extern(C) methods). --
[Issue 18432] alias x = x where x is an imported symbol should result in an error
https://issues.dlang.org/show_bug.cgi?id=18432
--- Comment #7 from Mike Franklin ---
Reduced test case
--- moduleA.d
module moduleA;
template TestTemplate() { }
--- moduleB.d
module moduleB;
import moduleA : TestTemplate;
alias TestTemplate = TestTemplate;
--- main.d
import moduleB;
alias TestTemplate = moduleB.TestTemplate;
void main() { }
compile with:
dmd main.d moduleA.d moduleB.d
--
[Issue 18502] New: isExpression treated differently in TemplateTypeParameterSpecialization than elsewhere
https://issues.dlang.org/show_bug.cgi?id=18502
Issue ID: 18502
Summary: isExpression treated differently in
TemplateTypeParameterSpecialization than elsewhere
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
enum Foo(alias T : Bar!U, U...) = true;
template Bar(T...) { alias b = T; }
// These compile as expected:
static assert(Foo!(Bar!int));
static assert(!__traits(compiles, Foo!(Bar!int)));
// While this asserts:
static assert(is(Bar!int : Bar!T, T...));
--
[Issue 18385] [REG 2.079] method cannot be overloaded with another extern(C) method
https://issues.dlang.org/show_bug.cgi?id=18385
--- Comment #6 from Jacob Carlborg ---
(In reply to Martin Nowak from comment #3)
> So you're bug report is about
>
> cat > bug.d << CODE
> struct S
> {
> extern(C) static void foo(int) {}
> extern(C) static void foo(double) {}
> }
> CODE
> dmd -c bug.d
>
> Error: function bug.S.foo(double) cannot be overloaded with another
> extern(C) function at /home/dawg/Code/D/bug.d(3)
>
>
> instead
> ?
Yes, I actually have a class. I just tried to reduce the test case as much as
possible.
--
[Issue 18385] [REG 2.079] method cannot be overloaded with another extern(C) method
https://issues.dlang.org/show_bug.cgi?id=18385 --- Comment #5 from Martin Nowak --- https://github.com/dlang/dmd/pull/7577/files#diff-3084a264389e086215b36670ae9f4a3dR386 --
[Issue 18385] [REG 2.079] method cannot be overloaded with another extern(C) method
https://issues.dlang.org/show_bug.cgi?id=18385 Martin Nowak changed: What|Removed |Added Summary|[REG nightly] function |[REG 2.079] method cannot |cannot be overloaded with |be overloaded with another |another extern(C) function |extern(C) method --
[Issue 18385] [REG nightly] function cannot be overloaded with another extern(C) function
https://issues.dlang.org/show_bug.cgi?id=18385 Martin Nowak changed: What|Removed |Added Status|RESOLVED|REOPENED CC||c...@dawg.eu Resolution|INVALID |--- --- Comment #4 from Martin Nowak --- (In reply to Walter Bright from comment #2) > Yes, it should never have compiled, and it cannot work, as two functions > with the same mangled name cannot both exist in the executable. Not so fast, the report about methods being broken is still somewhat valid. In that case `extern(C)` only affects the calling convention but not the mangling, and has mentioned use-cases as callbacks. It's relatively easy to just use different names for that use-case, so we might decide to deprecate this overloading if that seems necessary. --
[Issue 18385] [REG nightly] function cannot be overloaded with another extern(C) function
https://issues.dlang.org/show_bug.cgi?id=18385
--- Comment #3 from Martin Nowak ---
(In reply to Jacob Carlborg from comment #0)
> Note that global C function will not have a mangling, but methods of a
> struct or class declared as `extern (C)` will get mangled as a D method.
> This can be used as a callback function for a C function.
So you're bug report is about
cat > bug.d << CODE
struct S
{
extern(C) static void foo(int) {}
extern(C) static void foo(double) {}
}
CODE
dmd -c bug.d
Error: function bug.S.foo(double) cannot be overloaded with another extern(C)
function at /home/dawg/Code/D/bug.d(3)
instead
?
For top-level functions there is no way to just use C calling convention
without the mangling, so the example from the OP will clearly lead to a
multiple definition problem and undefined behavior dependening on various
linker behaviors.
Introduced here https://github.com/dlang/dmd/pull/7577.
BTW, please use [Reg ] instead of a non-permanent [Reg
nightly]. For nightlies it's the next major version, so 2.079.0 in your case.
--
[Issue 18385] [REG nightly] function cannot be overloaded with another extern(C) function
https://issues.dlang.org/show_bug.cgi?id=18385 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #2 from Walter Bright --- Yes, it should never have compiled, and it cannot work, as two functions with the same mangled name cannot both exist in the executable. --
[Issue 15217] overloaded extern(C) function declarations are allowed
https://issues.dlang.org/show_bug.cgi?id=15217 Mike Franklin changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18385 --
[Issue 18385] [REG nightly] function cannot be overloaded with another extern(C) function
https://issues.dlang.org/show_bug.cgi?id=18385 Mike Franklin changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15217 --
[Issue 12697] -inline ICE backend\el.c 802
https://issues.dlang.org/show_bug.cgi?id=12697 Mike Franklin changed: What|Removed |Added Status|NEW |RESOLVED CC||slavo5...@yahoo.com Resolution|--- |WORKSFORME --- Comment #3 from Mike Franklin --- I cannot reproduce this in 2.078.1 or master (80b606e11c53ef5b55196c83561e635471936f90) on 2018-02-23. Closing as WORKSFORME. --
[Issue 18385] [REG nightly] function cannot be overloaded with another extern(C) function
https://issues.dlang.org/show_bug.cgi?id=18385 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #1 from Mike Franklin --- I tested this at the module level: https://run.dlang.io/is/6iuGF4 It fails with a "multiple definition" linker error for 2.071.2 ~ 2.074.1. It succeeds beginning with 2.075.1, but displays a linker warning "Warning: size of symbol `foo` changed" I don't think this should have ever compiled, and I'm tempted to say that this bug has finally been fixed. But I would be delighted to be proven wrong. --
