[Issue 15056] [REG2.068.1] Unstored RAII struct return yields bogus error: "cannot mix core.std.stdlib.alloca() and exception handling"
https://issues.dlang.org/show_bug.cgi?id=15056 --- Comment #10 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6c7069c06b8a5b3f003955ce2d908b6c928823a2 add test for Issue 15056 https://github.com/D-Programming-Language/dmd/commit/ef854c328bf8798f3154dc923d1b7115acd97c70 Merge pull request #5110 from MartinNowak/workaround15056 --
[Issue 14708] destructor for temporary not called during stack unwinding
https://issues.dlang.org/show_bug.cgi?id=14708 github-bugzi...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 14708] destructor for temporary not called during stack unwinding
https://issues.dlang.org/show_bug.cgi?id=14708 --- Comment #7 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1a807d16b5d8ba87dbfd4344942a6708ef516896 Revert "fix Issue 14708 - destructor for temporary not called during stack unwinding" --
[Issue 15044] [REG2.068.0] destroy might leak memory
https://issues.dlang.org/show_bug.cgi?id=15044 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8e4676303a688ce3a034b38508b5e5b8c7bfa7e0 fix Issue 15044 - destroy might leak memory https://github.com/D-Programming-Language/dmd/commit/af4d3a4158f95d1720b42e8027ae2aead90c7a4f Merge pull request #5075 from 9rnsr/fix15044 --
[Issue 15079] Assertion `fd->semanticRun == PASSsemantic3done' failed.
https://issues.dlang.org/show_bug.cgi?id=15079 --- Comment #3 from Marc Schütz --- After running dustmite for two days, the power failed and everything was gone :-( Anyway, I managed to find a particular file that triggered the ICE when compiled separately, and could reduce it much faster with this knowledge, see attachment. > tar xf botan3.reduced.tar.gz && cd botan3.reduced > dmd -c -O -inline -release ./botan/algo_base/scan_token.d dmd: glue.c:809: void FuncDeclaration_toObjFile(FuncDeclaration*, bool): Assertion `fd->semanticRun == PASSsemantic3done' failed. I tried merging all the source files into one, but then the ICE disappeared. --
[Issue 15079] Assertion `fd->semanticRun == PASSsemantic3done' failed.
https://issues.dlang.org/show_bug.cgi?id=15079 --- Comment #4 from Marc Schütz --- Created attachment 1552 --> https://issues.dlang.org/attachment.cgi?id=1552&action=edit reduced testcase --
[Issue 15105] New: paths never work
https://issues.dlang.org/show_bug.cgi?id=15105 Issue ID: 15105 Summary: paths never work Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com I've run into yet more cases where default configuration seems to fail. I'm trying to 'Compile and Disassemble', and my compiler is set to LDC (x64 build). It just says: 'ldc2' is not recognized as an internal or external command, operable program or batch file. In the options -> 'LDC install path', I have the LDC install path (not /bin) I have also tried to set that to the /bin subdirectory, it doesn't work either way. When I press F7 to build, it does build. It's like it can find LDC when building, but not when disassembling...? Getting paths right is an endless nightmare. I've been using VisualD for 6 years, and I still can't seem to get the paths right. I'm gonna suggest a new strategy; rather than requiring user configuration, when VisualD can't find a path or tool, or for any other pathing related problem, I think it should present a dialog box prompting the user to find the path to the thing it wants. It should give a message saying what it wants (ie, "where is ldc2.exe?"), and then when the user selects a path, it should write that to the settings. This way, if the user fails to configure paths correctly (seems to be close to 100% of the time, especially on initial installation), rather than getting annoying errors, they will get a prompt to fix it, and it should just work from there on. Sound reasonable? --
[Issue 15106] New: Optlink executed with LDC as compiler?
https://issues.dlang.org/show_bug.cgi?id=15106 Issue ID: 15106 Summary: Optlink executed with LDC as compiler? Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com I select LDC as compiler, it builds and then invokes OPTLINK to link. It's even a 64bit project... I'm using the MSVC LDC build, it should use Microsoft's linker like DMD no? Building .\dsignal.exe... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 9: Unknown Option : NXCOMPAT OPTLINK : Warning 9: Unknown Option : DYNAMICBASE OPTLINK : Error 8: Illegal Filename /NOLOGO /NXCOMPAT /DYNAMICBASE /LARGEADDRESSAWARE /OPT:REF /OPT:ICF "/OUT:.\dsignal.exe" analyse.obj fft.obj stft.obj util.obj wave.obj window.obj plot.obj image.obj sound.obj normint.obj conv.obj hsx.obj package.obj rgb.obj xyz.obj test.obj "/LIBPATH:C:\dev\ldc2-0.16.0-alpha4-win64-msvc\bin/../lib" legacy_stdio_definitions.lib /LARGEADDRESSAWARE:NO "/MAP:obj\x64\Release\dsignal.map" /SUBSYSTEM:CONSOLE phobos2-ldc.lib druntime-ldc.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib ^ Error: C:\dev\D\dmd2\windows\bin\link.exe failed with status: 1 Building .\dsignal.exe failed! You can see from the lib path that it's definitely invoking LDC to build. --
[Issue 15107] New: Win32-COFF library paths are blank
https://issues.dlang.org/show_bug.cgi?id=15107 Issue ID: 15107 Summary: Win32-COFF library paths are blank Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Default installation, go into settings -> DMD directories -> 'Win32' and 'x64' both have 'library paths' configured, but 'Win32-COFF' is empty. What's strange though, is that the 'Win32' library paths (this is for the OMF build right?) are pointing to system lib dirs: Win32: $(DevEnvDir)..\..\VC\lib\amd64\ C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64 C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64 x64: $(VCInstallDir)\lib\amd64 $(WindowsSdkDir)Lib\win8\um\x64 C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64 Win32-COFF: Does that look right? --
[Issue 15108] New: DMD should support ARM
https://issues.dlang.org/show_bug.cgi?id=15108 Issue ID: 15108 Summary: DMD should support ARM Product: D Version: D2 Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com I'm surprised there is no open issue for this. ARM has become extremely popular with the rise of powerful mobile devices and small consumer computers like the raspberry pi. Getting DMD on ARM devices could pave the way for D on iPhones and Androids, as well as D ruling the hobbyist projects, as resources constraints become too hindering with scripting languages like Python. --
[Issue 15109] New: Always gets install dir wrong when uninstalling previous version
https://issues.dlang.org/show_bug.cgi?id=15109 Issue ID: 15109 Summary: Always gets install dir wrong when uninstalling previous version Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com When installing a new version, it first uninstalls the prior version. It always gets the install path wrong. The default install dir is C:\D, but I never install there (who wants to spam the root directory?), I install to C:\dev\D. It first offers to uninstall, but there is a greyed out (not-editable) text box showing C:\D (NOT where DMD is installed on my machine), and I can't do anything but click continue. It them complains that it can't find DMD at that path (no shit!), and fails to uninstall. It then proceeds to install the new version, but having failed to uninstall the prior version, it all gets a little messy. DMD installer should remember where it's installed. --
[Issue 15104] Switching fibers in finally blocks breaks EH
https://issues.dlang.org/show_bug.cgi?id=15104 David Nadlinger changed: What|Removed |Added Keywords||patch --- Comment #1 from David Nadlinger --- https://github.com/D-Programming-Language/druntime/pull/1397 --
[Issue 15110] New: pragma(inline) rarely works how I want it to
https://issues.dlang.org/show_bug.cgi?id=15110
Issue ID: 15110
Summary: pragma(inline) rarely works how I want it to
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
pragma(inline, true)
R normalisedSubtract(T, U, R = ResultType!(T, U))(T a, U b)
{
R x = cast(R)a;//convertNormInt!R(a);
R y = cast(R)b;//convertNormInt!R(b);
static if(isUnsigned!R)
{
if(x <= y)
return 0;
return cast(R)(x - y);
}
else
{
auto r = x - y;
if(r < R.min)
r = R.min;
else static if(isSigned!R)
{
if(r > R.max)
r = R.max;
}
return cast(R)r;
}
}
src\std\experimental\color\internal\normint.d(90): Error: function
std.experimental.color.internal.normint.normalisedSubtract!(ubyte, ubyte,
ubyte).normalisedSubtract cannot inline function
This function is literally nothing more than a single integer subtract.
I have no idea why this won't inline. I experience this general problem quite a
bit.
Strangely, the addition compliment to this function doesn't complain.
--
[Issue 15110] pragma(inline) rarely works how I want it to
https://issues.dlang.org/show_bug.cgi?id=15110 David Nadlinger changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #1 from David Nadlinger --- Didn't Walter just fix an issue like this in master? The problem is probably that DMD can't/couldn't inline "if (a) return b; return c;"-type constructs. --
[Issue 15111] New: hashOf fails for structs that are also ranges
https://issues.dlang.org/show_bug.cgi?id=15111
Issue ID: 15111
Summary: hashOf fails for structs that are also ranges
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: generic...@gmail.com
$ dmd --version
DMD64 D Compiler v2.068
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
$ cat app.d
import core.internal.hash;
struct Foo {
int[] arr;
alias arr this;
}
void main() {
Foo().hashOf();
}
$ dmd app.d
app.d(9): Error: core.internal.hash.hashOf called with argument types (Foo)
matches both:
/usr/include/dlang/dmd/core/internal/hash.d(40):
core.internal.hash.hashOf!(Foo).hashOf(Foo val, ulong seed)
and:
/usr/include/dlang/dmd/core/internal/hash.d(112):
core.internal.hash.hashOf!(Foo).hashOf(Foo val, ulong seed)
/usr/include/dlang/dmd/object.d(2999): Error: core.internal.hash.hashOf called
with argument types (Foo, ulong) matches both:
/usr/include/dlang/dmd/core/internal/hash.d(40):
core.internal.hash.hashOf!(Foo).hashOf(ref Foo val, ulong seed)
and:
/usr/include/dlang/dmd/core/internal/hash.d(112):
core.internal.hash.hashOf!(Foo).hashOf(ref Foo val, ulong seed)
app.d(9): Error: template instance object.hashOf!(Foo) error instantiating
--
[Issue 15106] Optlink executed with LDC as compiler?
https://issues.dlang.org/show_bug.cgi?id=15106 --- Comment #1 from Sobirari Muhomori --- http://forum.dlang.org/post/dktognsdovyxxukjb...@forum.dlang.org This is a common problem with compiler installers: you get PATH polluted with everything you ever installed, then something from that mess gets run when you try to invoke something else. --
[Issue 15111] hashOf fails for structs that have an alias this to a dynamic array
https://issues.dlang.org/show_bug.cgi?id=15111 David Nadlinger changed: What|Removed |Added CC||c...@klickverbot.at Summary|hashOf fails for structs|hashOf fails for structs |that are also ranges|that have an alias this to ||a dynamic array --
[Issue 15112] New: !is not highlighted
https://issues.dlang.org/show_bug.cgi?id=15112 Issue ID: 15112 Summary: !is not highlighted Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: alil...@gmail.com Version: VisualD 0.3.42 In VisualD, "!is" isn't highlighted like "is" is. --
[Issue 15113] New: we should automate checking of broken links on dlang.org. and fix std.typetuple page - link to std.meta is broken
https://issues.dlang.org/show_bug.cgi?id=15113 Issue ID: 15113 Summary: we should automate checking of broken links on dlang.org. and fix std.typetuple page - link to std.meta is broken Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: lae...@laeeth.com We should produce a report on broken links and dump it into the bug tracker regularly. Eg see here (but that was a one-off whereas we should have a process): https://issues.dlang.org/show_bug.cgi?id=14085 And we should fix the following (don't have time to do a pull request, sorry). http://dlang.org/phobos/std_typetuple.html Jump to: TypeTuple This module was renamed to disambiguate the term tuple, use std.meta instead. Link above to std.meta should be: http://dlang.org/phobos/std_meta.html But actually goes to: http://dlang.org/std_meta.html --
[Issue 15110] pragma(inline) rarely works how I want it to
https://issues.dlang.org/show_bug.cgi?id=15110 --- Comment #2 from Manu --- Okay. I've encountered this sort of problem a lot, it might all be the same problem though, this isn't exactly an uncommon pattern. --
[Issue 15106] Optlink executed with LDC as compiler?
https://issues.dlang.org/show_bug.cgi?id=15106 --- Comment #2 from Manu --- Is it really ideal to leave sourcing of the path to blind luck? Surely LDC can invoke microsoft's linker specifically? It's true, this is a very general problem. Pathing in general just doesn't work reliably. We need better solutions across the ecosystem. Perhaps software can attempt to identify if the first tool it finds is the correct tool, and then keep looking if it's not...? --
[Issue 15106] Optlink executed with LDC as compiler?
https://issues.dlang.org/show_bug.cgi?id=15106 David Nadlinger changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #3 from David Nadlinger --- The Visual Studio ecosystem works much the same way, though. This is why there is an extra command prompt to launch stuff with the MSVC tools on the PATH (plus of course some other env vars). --
[Issue 15106] Optlink executed with LDC as compiler?
https://issues.dlang.org/show_bug.cgi?id=15106 --- Comment #4 from Manu --- But I've _never_ had a single problem with visual studio of this sort in 16 years. I often have 3 or 4 versions of VS installed in parallel, they all just work together. Those command prompts do exist, but they're transparent to the end-user, it runs them when it needs them. I think those command prompts demonstrate that MS understand the pathing struggle, and they fixed it in a way that other stuff on the users systems tends not to interfere with. My point is, the D ecosystem across the board (not just picking on LDC here), needs to be more creative about solving this problem. It's tiring, and it basically hasn't changed for 6 years that I've been here. I had 3 distinct instances of pathing problem yesterday alone. Perhaps LDC (or VisualD?) should leverage those command prompts when building against the MSVC ecosystem (ie, LDC, DMD), rather than just hoping the path is configured correctly? Windows users don't do path management, it's always a complete mess. --
[Issue 15104] Switching fibers in finally blocks breaks EH
https://issues.dlang.org/show_bug.cgi?id=15104 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e Fix Issue 15104 - Fiber context switch in finally blocks breaks EH https://github.com/D-Programming-Language/druntime/commit/f0f8edaeb56294460aedbae3d91c7d3b304516b6 Merge pull request #1397 from klickverbot/fix-15104 Fix Issue 15104 - Fiber context switch in finally blocks breaks EH --
