[Issue 14424] New: dmd crashes with __traits(getUnitTests)
https://issues.dlang.org/show_bug.cgi?id=14424
Issue ID: 14424
Summary: dmd crashes with __traits(getUnitTests)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: critical
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: atila.ne...@gmail.com
To reproduce (I tried this under /tmp and it didn't work, but under
~/coding/d/crash it did):
example/example_crash.d:
void main() {
import tests.pass.crash;
__traits(getUnitTests, tests.pass.crash);
}
tests/pass/crash.d:
module tests.pass.crash;
unittest { }
Run `dmd -v -c -unittest example/example_crash.d`:
binarydmd
version v2.067
config/etc/dmd.conf
parse example_crash
importall example_crash
importobject(/usr/include/dlang/dmd/object.di)
semantic example_crash
entry main example/example_crash.d
semantic2 example_crash
semantic3 example_crash
importtests.pass.crash (tests/pass/crash.d)
zsh: segmentation fault (core dumped) dmd -v -c -unittest
example/example_crash.d
--
[Issue 14423] New: struct destructors not finalized for AA values
https://issues.dlang.org/show_bug.cgi?id=14423 Issue ID: 14423 Summary: struct destructors not finalized for AA values Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Since 2.067.0 struct allocated on the heap are finalized. This doesn't work for struct values of associative arrays. >From my undestanding we'd need to construct a synthetic TypeInfo to make this work, because what gets allocated is a "struct" consisting of the hash, the key, and the value. --
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #17 from Jens Bauer --- (In reply to Jens Bauer from comment #16) > As a fail-safe, an unsigned 32-bit counter could be used as an 'absolutely > maximum limit'. ... and if the 32-bit counter wraps, then an error message should be given to the user, for instance: "Error: Please write better code." ;) --
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #16 from Jens Bauer --- (In reply to Iain Buclaw from comment #15) > So then you just need to decide what is a suitable iteration limit, > short.max? ushort.max? If it's just to make sure that "we're not stuck forever", the size of the returned argument might be suitable. I believe this is very much a matter of opinion, though. But consider this. Combining with my previous idea of checking the exit-conditions. All sources for the exit-conditions should be saved (the stack would be fine): All minimum values for the exit conditions All maximum values for the exit conditions A minimumHit counter A maximumHit counter Each time the same minimum for all exit conditions are hit, then the minimumHit counter is incremented. If a new minimum is found, the minimumHit counter is cleared. Same thing for the maximumHit counter. Now if any of those two counters reach a value above - say 10, then we'll exit the loop. As a fail-safe, an unsigned 32-bit counter could be used as an 'absolutely maximum limit'. This is just an idea, but I believe it would be fairly good at catching more than 99% of the lockups. --
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 --- Comment #4 from Sönke Ludwig --- Just that "concatenation as paragraphs" instead of "concatenation as lines" precludes the use of this documentation style: /// This is the summary, possibly going /// over multiple lines. /// /// A large paragraph /// of text also /// gets split /// /// --- /// as well as code blocks behave awkwardly /// --- But it seems like maybe not many have tried to use this style in the past. --
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #15 from Iain Buclaw --- (In reply to yebblies from comment #14) > (In reply to Martin Nowak from comment #9) > > If you really think we should fix this, then a time limit for CTFE execution > > might be feasible. > > An iteration limit would be better than a time limit, because it will not be > dependent on environmental conditions. This would need to be configurable > from the command line etc. > > The compilation would terminate with a nice stack trace, making it easy to > debug. > So then you just need to decide what is a suitable iteration limit, short.max? ushort.max? --
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 --- Comment #3 from Kenji Hara --- (In reply to Sönke Ludwig from comment #2) > Do you know if that been a concious decision or is it just an artefact of > the implementation? I don't think it makes much sense as it is. Personally I > always use /** */ style comments, but anyone using /// is going to have > issues with it. At least http://dlang.org/ddoc says nothing about the case. It would be an artifact of the current dmd implementation, if there's no discussion in the old D forum (including digitalmars.d). But I think the "concatenation like paragraphs" is not bad. --
[Issue 14420] partial template ordering with specialization and different arities seems broken
https://issues.dlang.org/show_bug.cgi?id=14420
Kenji Hara changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Kenji Hara ---
(In reply to Martin Nowak from comment #0)
> void foo(string op:"+", T)(ref T val, T mod)
>
> void foo(string op, T, V1)(ref T val, V1 mod)
> ---
"Partial specialization order" is defined only when two templates have same
template parameters except for TemplateTypeParameterSpecialization. For
example:
template A(string op, T) {} // A1
template A(string op:"+", T) {} // A2 is a specialized version of A1
But in the OP code, Two 'foo's have different number of parameters, so neither
of them is not a specialized version of one another.
Therefore the ambiguous error is correct result.
--
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413
--- Comment #1 from Kenji Hara ---
(In reply to Sönke Ludwig from comment #0)
> ---
> /// This function is here to aid in making your
> /// software do cool stuff.
> void foo() {}
> ---
It's equivalent with:
---
/**
This function is here to aid in making your
software do cool stuff.
*/
void bar() {}
---
DMD lexer concatenates the continuous ddoc line comments like paragraphs. The
blank line is inserted to separate two one-liner paragraphs.
--
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 --- Comment #2 from Sönke Ludwig --- Do you know if that been a concious decision or is it just an artefact of the implementation? I don't think it makes much sense as it is. Personally I always use /** */ style comments, but anyone using /// is going to have issues with it. --
[Issue 14422] std.process: Pipes do not append to files on Win64
https://issues.dlang.org/show_bug.cgi?id=14422 Vladimir Panteleev changed: What|Removed |Added Keywords||pull --- Comment #2 from Vladimir Panteleev --- https://github.com/D-Programming-Language/phobos/pull/3160 --
[Issue 14422] std.process: Pipes do not append to files on Win64
https://issues.dlang.org/show_bug.cgi?id=14422
--- Comment #1 from Vladimir Panteleev ---
C program which reproduces this bug:
/// ctest.c ///
#include
#include
void main()
{
FILE *f;
PROCESS_INFORMATION pi = {0};
STARTUPINFO si = {sizeof(STARTUPINFO)};
f = fopen("test.txt", "w");
fprintf(f, "AA\n");
fclose(f);
f = fopen("test.txt", "a");
si.hStdOutput = (HANDLE)_get_osfhandle(_fileno(f));
si.dwFlags = STARTF_USESTDHANDLES;
CreateProcess(NULL, "cmd /c \"echo B\"",
NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi);
}
///
--
[Issue 14422] New: std.process: Pipes do not append to files on Win64
https://issues.dlang.org/show_bug.cgi?id=14422
Issue ID: 14422
Summary: std.process: Pipes do not append to files on Win64
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
test.d ///
import std.process;
import std.stdio;
import std.file;
void main()
{
auto fn = "fn.txt";
std.file.write(fn, "AA");
auto f = File(fn, "a");
spawnProcess(["cmd", "/c", "echo B"], stdin, f).wait();
auto data = readText(fn);
assert(data == "AAB\r\n", data);
}
///
This program runs fine on Win32, but the assert fails on Win64.
For some reason, the "a" mode is being ignored, and the content is written to
the beginning of the file, clobbering the original file header.
--
[Issue 14421] New: Variadic args array force on heap
https://issues.dlang.org/show_bug.cgi?id=14421
Issue ID: 14421
Summary: Variadic args array force on heap
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: john.loughran.col...@gmail.com
char[] foo(char[] args ...)
{
return args;
}
This is obviously wrong code, as args can be allocated on the stack. However,
it might not be.
Currently the only way out is to go `return args.dup` but that can lead to
allocating twice.
--
[Issue 14420] partial template ordering with specialization and different arities seems broken
https://issues.dlang.org/show_bug.cgi?id=14420 --- Comment #1 from Ketmar Dark --- i'm expecting the same (with second instantiates non-specialized template, which it does currently). --
[Issue 14419] [CTFE] Need infinite loop detection?
https://issues.dlang.org/show_bug.cgi?id=14419 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #14 from yebblies --- (In reply to Martin Nowak from comment #9) > If you really think we should fix this, then a time limit for CTFE execution > might be feasible. An iteration limit would be better than a time limit, because it will not be dependent on environmental conditions. This would need to be configurable from the command line etc. The compilation would terminate with a nice stack trace, making it easy to debug. (In reply to Jens Bauer from comment #10) > 1: on dlang.org, there's an on-line compiler. It wouldn't take much effort > to bring it to the knees. It's trival to make a D program that will take a very very long time to compile, even without infinite loops. --
[Issue 14420] New: partial template ordering with specialization and different arities seems broken
https://issues.dlang.org/show_bug.cgi?id=14420
Issue ID: 14420
Summary: partial template ordering with specialization and
different arities seems broken
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
void foo(string op:"+", T)(ref T val, T mod)
{
}
void foo(string op, T, V1)(ref T val, V1 mod)
{
}
void main()
{
int i32 = 12;
foo!"+"(i32, 13); // should match first
ubyte u8;
foo!"+"(u8, 1); // not sure about this one
}
---
Maybe my intuition is wrong here, but it's surprising that the first template
function which is specialized for op:"+" isn't called.
--
[Issue 14350] Unit test failures are not displayed in Windows GUI programs
https://issues.dlang.org/show_bug.cgi?id=14350 --- 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/6833d64a4f3ab2fb7af979ddf9ab1558dd369606 fix Issue 14350 - Unit test failures are not displayed in Windows GUI programs https://github.com/D-Programming-Language/druntime/commit/de0c8495054995fbb0237f53c9752ebd65884034 Merge pull request #1200 from CyberShadow/pull-20150327-170332 fix Issue 14350 - Unit test failures are not displayed in Windows GUI pr... --
[Issue 14350] Unit test failures are not displayed in Windows GUI programs
https://issues.dlang.org/show_bug.cgi?id=14350 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
