[Issue 1578] Allow AA literals to initialize static variables
https://issues.dlang.org/show_bug.cgi?id=1578 Xiao Di Guan changed: What|Removed |Added CC||x...@puxlit.net --
[Issue 16572] can't take inout delegate
https://issues.dlang.org/show_bug.cgi?id=16572 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #5 from Adam D. Ruppe --- See my comment on Github regarding a hacky fix, with the commit that introduced this bug and some logic behind my reasoning. I'm sure Walter (or someone who knows dmd well) can get a non-hack fix easily: https://github.com/dlang/dmd/commit/3c53a0fd9ed1b40f8dbeb75b4dfa11f6df5b3062#commitcomment-19312704 --
[Issue 16095] a delegate can mutate immutable data and break shared / non-shared enforcements
https://issues.dlang.org/show_bug.cgi?id=16095 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #5 from Adam D. Ruppe --- The fix created a new bug... see my comment here https://github.com/dlang/dmd/commit/3c53a0fd9ed1b40f8dbeb75b4dfa11f6df5b3062#commitcomment-19312704 --
[Issue 16570] [REG 2.072.0-b1] Enum member with interpreted initializer has type of initializer not enum
https://issues.dlang.org/show_bug.cgi?id=16570 Martin Nowak changed: What|Removed |Added Keywords||pull --- Comment #2 from Martin Nowak --- https://github.com/dlang/dmd/pull/6175 --
[Issue 16598] New: [REG2.069] ICE with void ternary + finalizers
https://issues.dlang.org/show_bug.cgi?id=16598
Issue ID: 16598
Summary: [REG2.069] ICE with void ternary + finalizers
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
test.d ///
struct S
{
this(int) {}
~this() {}
}
int g(S a, S b)
{
return 1;
}
void main()
{
true ? g(S(), S(1)) : {}();
}
///
Produces:
Internal error: backend/cod1.c 1654
Introduced in https://github.com/D-Programming-Language/dmd/pull/5003
--
[Issue 16597] Initializing a shared hashmap segfaults
https://issues.dlang.org/show_bug.cgi?id=16597 --- Comment #1 from Andrej Mitrovic --- DMD 2.071.1 on both Linux and Win32. --
[Issue 16597] New: Initializing a shared hashmap segfaults
https://issues.dlang.org/show_bug.cgi?id=16597
Issue ID: 16597
Summary: Initializing a shared hashmap segfaults
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
I don't understand how something this basic can segfault.
-
shared int[int] aa;
void main ( ) { aa = [1:1, 2:2]; }
-
--
[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior
https://issues.dlang.org/show_bug.cgi?id=16588 Ali Cehreli changed: What|Removed |Added Keywords||industry --
[Issue 15988] [REG v2.070] Massive Compile Time Slowdown
https://issues.dlang.org/show_bug.cgi?id=15988 Jack Stouffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jack Stouffer --- I'll just close this then --
[Issue 16566] hasLength should enforce that length has type size_t
https://issues.dlang.org/show_bug.cgi?id=16566 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #2 from Jonathan M Davis --- (In reply to Sophie from comment #1) > What is the rationale for disallowing other numeric primitives for length, > or types that act like numeric primitives? It complicates code considerably for it to have to worry about length being anything other than size_t, and the vast majority of existing code assumes that length is size_t. Anything else just plain doesn't play well with a lot of code, and making it play well would require being very careful about how length was handled every time it was used. At one point, iota was changed so that it supported ulong for length so that ranges over long or ulong could have a length and contain the full range of values for long or ulong on a 32-bit system. It caused more trouble than it was worth, and we changed it so that iota's length was always size_t once again. The newsgroup discussion that Andrei opened up in relation to this bug report: http://forum.dlang.org/post/nsn75s$v8q$1...@digitalmars.com --
[Issue 16596] REGRESSION:`digger build` fails:Undefined symbols for architecture x86_64 symboldata
https://issues.dlang.org/show_bug.cgi?id=16596 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution|--- |DUPLICATE --- Comment #3 from Martin Nowak --- *** This issue has been marked as a duplicate of issue 16536 *** --
[Issue 16536] DMD master does not build on OS X 10.11.6/Xcode 7.3.1
https://issues.dlang.org/show_bug.cgi?id=16536 Martin Nowak changed: What|Removed |Added CC||timothee.co...@gmail.com --- Comment #8 from Martin Nowak --- *** Issue 16596 has been marked as a duplicate of this issue. *** --
[Issue 15988] [REG v2.070] Massive Compile Time Slowdown
https://issues.dlang.org/show_bug.cgi?id=15988 --- Comment #5 from Martin Nowak --- I heard back that the problem was no longer reproducible with their latest codebase and the latest dmd compiler, though it's a bit unclear what fixed it, but the old state can't be easily tested any longer. --
[Issue 16580] [REG 2.072.0-b1] spawnShell segfaults on macOS
https://issues.dlang.org/show_bug.cgi?id=16580 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 16580] [REG 2.072.0-b1] spawnShell segfaults on macOS
https://issues.dlang.org/show_bug.cgi?id=16580 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/ebbdf21a7ebc6730a3d5f170b934143bdb18a414 fix Issue 16580 - spawnShell segfaults on macOS - partially Revert "Merge pull request #4493 from schveiguy/fixcycles2" - recreate processinit (and import it from std.process) to call std.process shared ctor w/o creating a cycle - keep it separate from phobosinit to not drag std.encoding into any binary using std.process --
[Issue 16291] phobosinit never gets called (EncodingScheme.create fails)
https://issues.dlang.org/show_bug.cgi?id=16291 --- Comment #29 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9d73d18c0cd4ecd1bb1ebc8bb01941f209570ca2 fix Issue 16291 - EncodingScheme.create fails - add EncodingScheme.register overload that references the registered class - just adding the FQN name of a class does not reference that class, so it must not end up in the binary and subsequently EncodingScheme.create failed - This used to work by chance b/c all the EncodingScheme implementations were in a module w/ static ctor. Any user of std.encoding did drag in that ModuleInfo, which in turn referenced all classes of std.encoding. Since moving the static ctor to std.internal.phobosinit to break a cycle, the classes were no longer referenced by a ModuleInfo w/ shared ctor, so they wouldn't end up in the binary unless explicitly referenced elsewhere. - deprecate the old EncodingScheme.register(string fqn) b/c relying on Object.factory is slow, error prone (linkage), and really unnecessary - import encodinginit in std.encoding so that the std_encoding_shared_static_this callback actually gets run https://github.com/dlang/phobos/commit/ad739f232ea93f56b9f72920be49d999a2507652 Merge pull request #4840 from MartinNowak/fix16291 fix Issue 16291 - EncodingScheme.create fails --
[Issue 16596] REGRESSION:`digger build` fails:Undefined symbols for architecture x86_64 symboldata
https://issues.dlang.org/show_bug.cgi?id=16596 Timothee Cour changed: What|Removed |Added Summary|REGERSSION:`digger build` |REGRESSION:`digger build` |fails:Undefined symbols for |fails:Undefined symbols for |architecture x86_64 |architecture x86_64 |symboldata |symboldata --
[Issue 16596] REGERSSION:`digger build` fails:Undefined symbols for architecture x86_64 symboldata
https://issues.dlang.org/show_bug.cgi?id=16596 Timothee Cour changed: What|Removed |Added Summary|`digger build` |REGERSSION:`digger build` |fails:Undefined symbols for |fails:Undefined symbols for |architecture x86_64 |architecture x86_64 |symboldata |symboldata --
[Issue 16596] `digger build` fails:Undefined symbols for architecture x86_64 symboldata
https://issues.dlang.org/show_bug.cgi?id=16596 Timothee Cour changed: What|Removed |Added CC||timothee.co...@gmail.com --- Comment #2 from Timothee Cour --- digger: bff7b4fe36e34b8db6aed33b91536ac0efed75f6 is the first bad commit commit bff7b4fe36e34b8db6aed33b91536ac0efed75f6 Author: Andrei Alexandrescu Date: Wed Sep 21 14:01:59 2016 -0400 dmd: Merge pull request #6145 from WalterBright/add-dmsc.d https://github.com/D-Programming-Language/dmd/pull/6145 convert msc.c to dmsc.d diff --git a/dmd b/dmd index cce7909..93596df 16 --- a/dmd +++ b/dmd @@ -1 +1 @@ -Subproject commit cce79099fd365ee0a2aaf0e3ec4141303ea28e46 +Subproject commit 93596df0c5cf2fc272ea0841f2f263e53cb1e47e digger: Bisection completed successfully. --
[Issue 15862] dmd thinks functions are strongly pure despite mutable indirections in the return type
https://issues.dlang.org/show_bug.cgi?id=15862
--- Comment #6 from Steven Schveighoffer ---
(In reply to Walter Bright from comment #2)
> This is as designed and intended.
>
> 1. Mutable indirections in the return type do not affect purity
> determination. Mutability of the parameters does.
The function can still be strong-pure, in that the result will always be the
same for the same parameters. You can elide the call, but the result must be
copied -- it cannot be identical.
That is, it is OK for the compiler to optimize by changing OP's code to this:
int* p1 = p();
int* p2 = new int(*p1);
if (p1 is p2) throw new Exception("pointers same");
int[] a1 = a();
int[] a2 = a1.dup;
if (a1 is a2) throw new Exception("arrays same");
Object o1 = o();
Object o2 = deepCopy(o);
if (o1 is o2) throw new Exception("objects same");
> 2. An early design decision was that calling new() inside a pure function is
> an acceptable special case. (Otherwise pure functions would be nearly
> useless.)
Right, but all pure memory allocations should not return the same piece of
memory!
--
[Issue 16265] unittest imports should not be counted as dependencies for static ctors
https://issues.dlang.org/show_bug.cgi?id=16265 Steven Schveighoffer changed: What|Removed |Added Summary|batter detection of real|unittest imports should not |module cycles |be counted as dependencies ||for static ctors --- Comment #3 from Steven Schveighoffer --- unittest dependencies cannot be called directly by static constructors (except by Martin's corner case method), so their imports don't count when doing construction. By the time unittests run, static ctors are already done, so no worries there. (In reply to Martin Nowak from comment #2 > Well, unfortunately it's technically possible using `__traits(getUnitTests, > __MODULE__)`, > and it wouldn't be too far-fetched to call the tests from a static ctor. I disagree this is not far-fetched, do we need to screw up everyone's cycle detection code due to this rare case? Isn't it enough to just say "WARNING unit test imports are not considered during static construction, calling unit tests during static construction can result in undetected cycles"? Consider that documented unit tests are meant to show how one can use a library call, and this might involve importing many other modules that are totally unrelated. Including unittest imports when doing cycle detection is harmful in many ways, it is very advantageous to get rid of this. Please, open a new bug report for other ideas of cycle detection improvement, don't override the purpose of this one. --
[Issue 15482] new uuid.d forbids to link statically with other libraries
https://issues.dlang.org/show_bug.cgi?id=15482 Manu changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #4 from Manu --- Turns out the symbols are in druntime (I also couldn't find them in phobos!). druntime also has a uuid.d file, so the same object filename, and the symbols are in there. It seems that druntime and phobos are aggregated into one lib? Weird, but okay... Anyway... I'm not entirely sure these symbols should be in druntime. Why are they there? Why can't users just link the usual libs that supple them? Those libs are now mutually exclusive with phobos, and that's a big problem. --
[Issue 15862] dmd thinks functions are strongly pure despite mutable indirections in the return type
https://issues.dlang.org/show_bug.cgi?id=15862 --- Comment #5 from ag0ae...@gmail.com --- (In reply to anonymous4 from comment #4) > Proper test case: > > int[] a=f(); > int[] b=f(); > a[0]=0; > b[0]=1; > assert(a[0]==0 && b[0]==1); You can't use asserts (except for assert(false)) to test this. The bug needs -release to occur, and -release disables asserts. --
[Issue 16547] -betterC switch no longer removes druntime symbols
https://issues.dlang.org/show_bug.cgi?id=16547
Jacob Carlborg changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||d...@me.com
Resolution|INVALID |---
--- Comment #3 from Jacob Carlborg ---
$ cat main.d
module main;
extern (C) int printf(in char*, ...);
extern (C) void main()
{
printf("asd\n");
}
$ dvm use 2.070.0
$ dmd --version
DMD64 D Compiler v2.070.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
$ dmd -betterC main.d
$ nm main | wc -l
4
$ dvm use 2.071.0
$ dmd --version
DMD64 D Compiler v2.071.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
$ dmd -betterC main.d
$ nm main | wc -l
2428
--
[Issue 15862] dmd thinks functions are strongly pure despite mutable indirections in the return type
https://issues.dlang.org/show_bug.cgi?id=15862 --- Comment #4 from anonymous4 --- Proper test case: int[] a=f(); int[] b=f(); a[0]=0; b[0]=1; assert(a[0]==0 && b[0]==1); --
[Issue 16591] Spawn process on windows fails for npm start
https://issues.dlang.org/show_bug.cgi?id=16591
--- Comment #2 from anonymous4 ---
Ah, it's a batch file, then use spawnShell("npm.cmd start",...)
--
[Issue 16591] Spawn process on windows fails for npm start
https://issues.dlang.org/show_bug.cgi?id=16591 --- Comment #1 from anonymous4 --- CreateProcessW supports running only executables, and I suppose npm is a script. Try to run the actual V8 interpreter executable. --
[Issue 16547] -betterC switch no longer removes druntime symbols
https://issues.dlang.org/show_bug.cgi?id=16547 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution|--- |INVALID --- Comment #2 from Martin Nowak --- Can't reproduce any significant different among 2.069.x - 2.070.2-b1 either. Guess this is a confusion b/c the program was still linked w/ phobos. Also see issue 11881 for a few shortcomings w/ the current -betterC state. --
[Issue 15482] new uuid.d forbids to link statically with other libraries
https://issues.dlang.org/show_bug.cgi?id=15482 anonymous4 changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #3 from anonymous4 --- Another case: https://forum.dlang.org/post/mailman.892.1475632667.2994.digitalmar...@puremagic.com --
