[Issue 17571] New: Cannot create alias of __traits(getMember
https://issues.dlang.org/show_bug.cgi?id=17571 Issue ID: 17571 Summary: Cannot create alias of __traits(getMember Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: shac...@weka.io Consider the following program: import unistd = core.sys.posix.unistd; alias func = __traits(getMember, unistd, "write"); When trying to compile: test.d(3): Error: basic type expected, not __traits test.d(3): Error: semicolon expected to close alias declaration test.d(3): Error: declaration expected, not '__traits' Since unistd.write is a function, there is no reason for me not to be able to create an alias of it. The only reason I'm marking this as a minor issue is because there is a workaround: import unistd = core.sys.posix.unistd; import std.meta; alias func = Alias!(__traits(getMember, unistd, "write")); This, however, goes outside the definition of what std.meta.Alias was meant for. It was meant for aliasing non-aliasable objects, not for aliasing functions (which is what is happening in this case). --
[Issue 17570] New: Misleading error message illegal conditional function definition
https://issues.dlang.org/show_bug.cgi?id=17570
Issue ID: 17570
Summary: Misleading error message illegal conditional function
definition
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: shac...@weka.io
Consider the following program:
import std.traits;
struct S(T) {
void func() if(isIntegral!T) {
}
}
Currently, it produces the following error message:
test.d(4): Error: semicolon expected following function declaration
test.d(4): Error: declaration expected, not 'if'
test.d(7): Error: } expected following members in struct declaration at
test.d(3)
The error message it should be producing is:
test.d(4): Error: cannot use conditional definition for non-template functions.
Use "static if" instead.
--
[Issue 3031] scoped static var conflicts
https://issues.dlang.org/show_bug.cgi?id=3031 feklushkin.de...@gmail.com changed: What|Removed |Added CC||feklushkin.de...@gmail.com --
[Issue 17352] [REG 2.075a] Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition
https://issues.dlang.org/show_bug.cgi?id=17352
--- Comment #6 from Martin Nowak ---
cat > bug.d << CODE
void bug(Args...)()
{
}
void test(bool coin)
{
if (coin)
{
string foobar;
bug!foobar();
}
else
{
string foobar;
bug!foobar();
}
}
CODE
dmd -c bug.d
Internal error: ddmd/backend/elfobj.c 1739
This is a real instance of this bug caused by ambiguous mangling of local
variables (see issue 14831).
Interestingly enough `void bug(alias var)()` only outputs a single template
instance :o.
--
[Issue 17559] [REG2.073.0] Wrong line number in stack trace
https://issues.dlang.org/show_bug.cgi?id=17559 --- Comment #6 from Vladimir Panteleev --- How do you define a regression? If something worked and now it doesn't work then it's a regression from the user's perspective. When latent bugs are exposed by some change or another, it doesn't matter how long said bugs were there. --
[Issue 17559] [REG2.073.0] Wrong line number in stack trace
https://issues.dlang.org/show_bug.cgi?id=17559 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #5 from Walter Bright --- This is not a regression. The code deleted by https://github.com/dlang/dmd/pull/6947 has been there for 30 years. --
[Issue 17523] Sporadic ICEs with inline asm
https://issues.dlang.org/show_bug.cgi?id=17523 --- Comment #18 from Vladimir Panteleev --- (In reply to Vladimir Panteleev from comment #15) > I'm going to bisect what caused the behaviour change, just to ensure that > the bug disappeared because of a codegen fix, and not because some random > change made it no longer manifest for that test case. Done. Bisecting the version to bootstrap DMD really put Digger to the test, and I needed to make some upgrades :) The bug was fixed in this PR: https://github.com/dlang/dmd/pull/5924 It does seem to be a fix in the backend, but it fixes an ICE, not resulting codegen. Does that make sense to you? --
[Issue 17567] make shared methods callable on unshared objects (and covariant)
https://issues.dlang.org/show_bug.cgi?id=17567 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright --- (In reply to Martin Nowak from comment #2) > It already seemed too simple to work out :). We worked out the rules for implicit conversions (used for covariance/contravariance) back when we came up with const/shared/etc. It's best to derive these in isolation, and then apply them without needing to work it out again. (It's a lot like using the chain rule for derivatives. Derive the chain rule, prove it's correct, then just apply it as a given.) I've gone through the same process with scope conversions. I kept confusing myself until I finally sat down and worked up a chart with the rules, convinced myself that that was correct, and then just applied them without worrying about it. --
[Issue 17224] Foreach documentation still refers to TypeTuples, rather than AliasSequences
https://issues.dlang.org/show_bug.cgi?id=17224 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/f381477bdcc647a739d16d3cbf5bf9c417526320 Issue 17224 - Foreach documentation still refers to TypeTuples, rather than AliasSequences https://github.com/dlang/phobos/commit/32b53346ff1930ac600fabc6c70352e861d28838 Merge pull request #5484 from wilzbach/fix-17224 Issue 17224 - Foreach documentation still refers to TypeTuples, rather than AliasSequences merged-on-behalf-of: Jack Stouffer --
[Issue 17569] New: Rename dman in the Debian .deb package to prevent conflict with Debian package debian-goodies
https://issues.dlang.org/show_bug.cgi?id=17569 Issue ID: 17569 Summary: Rename dman in the Debian .deb package to prevent conflict with Debian package debian-goodies Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: hst...@quickfur.ath.cx This was reported on the forum: Installing dmd if debian-goodies is installed fails. Both try to write a file named '/usr/bin/dman' [...snip...] sudo dpkg -i dmd_2.074.1-0_amd64.1.deb (Reading database ... 224610 files and directories currently installed.) Preparing to unpack dmd_2.074.1-0_amd64.1.deb ... Unpacking dmd (2.074.1-0) ... dpkg: error processing archive dmd_2.074.1-0_amd64.1.deb (--install): trying to overwrite '/usr/bin/dman', which is also in package debian-goodies 0.74 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) sudo dpkg -i dmd_2.075.0~b1-0_amd64.deb (Reading database ... 224610 files and directories currently installed.) Preparing to unpack dmd_2.075.0~b1-0_amd64.deb ... Unpacking dmd (2.075.0~b1-0) ... dpkg: error processing archive dmd_2.075.0~b1-0_amd64.deb (--install): trying to overwrite '/usr/bin/dman', which is also in package debian-goodies 0.74 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) The package debian-goodies also ships a binary named `dman`, with this description: - dman - Fetch manpages from online manpages.debian.org service - Since this is something shipped with Debian itself, I recommend either (1) renaming our dman utility to something less ambiguous, or (2) excluding it from the .deb package for dmd altogether. And on that note, just in case, I highly recommend *against* putting a Conflicts: line in the debian/control file, because there is no good reason why the debian-goodies package should be excluded by the dmd package. If anything, we should be the ones to give up the dman utility (I have never found a need for it, and I question whether anyone actually uses it besides the D developers). I'm marking this as a major bug, because the conflict means that any Debian user who wants to try out D for the first time may get immediately turned away by the installation failure due to some silly marginal utility being unfortunately named, just because he happens to have the debian-goodies package installed. --
[Issue 17568] [scope] addresses to fields can be escaped from scope method
https://issues.dlang.org/show_bug.cgi?id=17568 ag0ae...@gmail.com changed: What|Removed |Added Keywords||safe CC||ag0ae...@gmail.com --
[Issue 17568] [scope] addresses to fields can be escaped from scope method
https://issues.dlang.org/show_bug.cgi?id=17568 Martin Nowak changed: What|Removed |Added Priority|P1 |P2 Hardware|x86_64 |All OS|Linux |All Severity|enhancement |normal --
[Issue 17568] New: [scope] addresses to fields can be escaped from scope method
https://issues.dlang.org/show_bug.cgi?id=17568
Issue ID: 17568
Summary: [scope] addresses to fields can be escaped from scope
method
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
int* p;
struct T
{
int a;
void escape() @safe scope
{
p = &a;
}
}
void escape() @safe
{
{
T t;
t.escape;
}
auto bug = *p;
}
CODE
dmd -c -dip1000 bug
Tested with v2.075.0-b1
--
[Issue 17567] make shared methods callable on unshared objects (and covariant)
https://issues.dlang.org/show_bug.cgi?id=17567 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Martin Nowak --- (In reply to Andrei Alexandrescu from comment #1) > At this point we have threads getting shared access to x, but the current > thread believes x is unshared. It already seemed too simple to work out :). So this would only work with some inout flavor of shared which likely wouldn't be worth the trouble. --
[Issue 17567] make shared methods callable on unshared objects (and covariant)
https://issues.dlang.org/show_bug.cgi?id=17567
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@erdani.com
--- Comment #1 from Andrei Alexandrescu ---
This is not possible. Thanks Timon Gehr for explaining this to me. Consider:
shared int* p;
struct S
{
int x;
void func() shared { p = &x; }
}
void bug()
{
auto p = new S;
p.func;
++p.x;
}
At this point we have threads getting shared access to x, but the current
thread believes x is unshared.
--
[Issue 17560] Enhancement: view and copy full code example for offline compile/play
https://issues.dlang.org/show_bug.cgi?id=17560 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/72f109646392dd412e77dc6db1a2cbe34285c9a2 Add 'Open in editor' button for runnable code examples Fix Issue 17560 - Enhancement: view and copy full code example for offline compile/play --
[Issue 17567] New: make shared methods callable on unshared objects (and covariant)
https://issues.dlang.org/show_bug.cgi?id=17567
Issue ID: 17567
Summary: make shared methods callable on unshared objects (and
covariant)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
struct S
{
void func() shared {}
}
void bug()
{
S s;
s.func;
}
dmd -c bug
bug.d(9): Error: shared method bug.S.func is not callable using a non-shared
object
cat > bug2.d << CODE
interface I
{
void func();
}
class C : I
{
void func() shared {}
}
CODE
dmd -c bug
bug.d(5): Error: class bug.C interface function 'void func()' is not
implemented
Both of these use-cases should be supported. Shared on a methods guarantees
thread-safety which is compatible with being used in an unshared manner.
Therefor shared methods should be fully covariant to unshared methods.
This does not touch shared as type qualifier, `shared(T)` means the type is
shared between threads, and hence is obviously not convertible to `T`.
Looks like this would be the first storage class where we'd support covariance
and real overloading.
While overloading, e.g. `nothrow` and non-`nothrow` methods is not an error,
the compiler always prefers `nothrow`, `pure`, `@safe`, or `@nogc` methods.
But overloading should prefer unshared methods over `shared` ones, e.g. because
the methods might avoid using a mutex.
--
[Issue 17561] @safe code can write beyond Fiber's stack, despite guard page
https://issues.dlang.org/show_bug.cgi?id=17561 --- Comment #2 from ag0ae...@gmail.com --- Same issue applies to the main stack. Filed separately: issue 17566. --
[Issue 17566] New: can use void initialization in @safe code to break out of stack
https://issues.dlang.org/show_bug.cgi?id=17566
Issue ID: 17566
Summary: can use void initialization in @safe code to break out
of stack
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
This is basically issue 17561 but without `Fiber`s. A fix for this is likely to
also fix issue 17561, so 17561 could be considered a duplicate of this. I'm
leaving it open for now, because it might be solvable by working around the
more general issue somehow.
Related links:
* https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
* https://github.com/dlang/druntime/pull/1698
Memory corrupting code:
import core.sys.posix.sys.mman;
import std.conv: text;
enum pageSize = 1024 * 4; // 4 KiB
enum stackSize = 1024 * 1024 * 3; // 3 MiB
void main()
{
/* Allocate memory near the stack. */
ubyte foo;
auto stackTop = &foo + pageSize - cast(size_t) &foo % pageSize;
auto stackBottom = stackTop - stackSize;
auto sz = pageSize;
void* dst = stackBottom - sz;
void* p = mmap(dst, sz, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-1, 0);
assert(p == dst, "failed to allocate page");
/* Set it up with zeroes. */
auto mem = cast(ubyte[]) p[0 .. sz];
mem[] = 0;
foreach (x; mem) assert(x == 0, text(x)); /* passes */
/* Break out of the stack and wreak havoc. */
wreak_havoc();
/* Look at the mess. */
foreach (x; mem) assert(x == 0, text(x)); /* fails; prints "13" */
}
void wreak_havoc() @safe
{
ubyte[stackSize] x = void;
x[0] = 13;
}
Like in issue 17561, the surrounding code is not @safe, but is actually safe
(as far as I can tell). It's the void initialized static array that breaks
safety.
In a 32-bit program it's also possible to get there with `malloc` instead of a
targeted `mmap`:
/* WARNING: This fails quickly for me in a 32-bit Ubuntu VM, but it can
potentially consume all memory. */
import core.stdc.stdlib: malloc;
import std.conv: text;
enum pageSize = 1024 * 4; // 4 KiB
enum stackSize = 1024 * 1024 * 3; // 3 MiB
void main()
{
ubyte foo;
auto stackTop = &foo + pageSize - cast(size_t) &foo % pageSize;
auto stackBottom = stackTop - stackSize;
assert(cast(size_t) stackBottom % pageSize == 0);
while (true)
{
/* Allocate memory. */
auto sz = 1024 * 1024; // 1 MiB
auto p = malloc(sz);
assert(p !is null, "malloc failed");
assert(stackBottom > p);
/* See if it's near the stack. */
size_t distance = stackBottom - p;
if (distance <= sz)
{
/* Set it up with zeroes. */
auto mem = cast(ubyte[]) p[0 .. sz];
mem[] = 0;
foreach (x; mem) assert(x == 0, text(x)); /* passes */
/* Break out of the stack and wreak havoc. */
wreak_havoc();
/* Look at the mess. */
foreach (x; mem) assert(x == 0, text(x)); /* fails; prints "13" */
break;
}
}
}
void wreak_havoc() @safe
{
ubyte[stackSize] x = void;
x[0] = 13;
}
--
[Issue 17565] New: Rename theAllocator to threadAllocator
https://issues.dlang.org/show_bug.cgi?id=17565 Issue ID: 17565 Summary: Rename theAllocator to threadAllocator Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: slud...@outerproduct.org The current name doesn't convey the message that this is a thread-local allocator. The relation to processAllocator also isn't quite clear. The private variable that backs theAllocator is already named _threadAllocator and doing the same for the accessor property is arguably the most logical choice. --
[Issue 17564] New: std.experimental.allocator.theAllocator is null within shared static this
https://issues.dlang.org/show_bug.cgi?id=17564 Issue ID: 17564 Summary: std.experimental.allocator.theAllocator is null within shared static this Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: slud...@outerproduct.org vibe.d needs to use "shared static this" for initialization to support the original initialization scheme for applications that it still in wide use. With 2.075.0-b1, since processAllocator now returns an ISharedAllocator, it had to switch to theAllocator where possible. However, since this returns null during the "shared static this" phase, this causes a crash on startup. Setting theAllocator to something else also doesn't work, because of an assertion in std.experimental.allocator. Proposed change is to make initialization lazy, just as for processAllocator. --
[Issue 12555] Incorrect error ungagging for speculatively instantiated class
https://issues.dlang.org/show_bug.cgi?id=12555 Vladimir Panteleev changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #5 from Vladimir Panteleev --- *** Issue 11195 has been marked as a duplicate of this issue. *** --
[Issue 11195] Error messages not suppressed in __traits(compiles,...) for template instantiation nested in aggregate
https://issues.dlang.org/show_bug.cgi?id=11195 Vladimir Panteleev changed: What|Removed |Added CC||dlang-bugzilla@thecybershad ||ow.net Resolution|FIXED |DUPLICATE --- Comment #4 from Vladimir Panteleev --- (In reply to Simen Kjaeraas from comment #3) > This has apparently been solved some time in the last 4 years. Fixed in 2.066.0 by https://github.com/dlang/dmd/pull/3514 *** This issue has been marked as a duplicate of issue 12555 *** --
[Issue 2372] Template parameter types given as template parameter inhibits template instantiation + missing line number
https://issues.dlang.org/show_bug.cgi?id=2372
Simen Kjaeraas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #4 from Simen Kjaeraas ---
Jonathan Marler's code does indeed exhibit the same issue, and gives a small
demonstration of why this will never work in the general case. For a more
explicit demonstration:
void foo(T)(Bar!T value) {}
template Bar(T) {
alias Bar = string;
}
foo("test"); // What is T?
Clearly, in this case T cannot be determined. Real life examples could be
significantly more complex, and even involve CTFE and string mixins. There's
simply no way to make this work in the language.
--
[Issue 1997] Better type inference for templated types
https://issues.dlang.org/show_bug.cgi?id=1997 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Simen Kjaeraas --- This issue is not fixable in the general case - constructor arguments do not necessarily line up with type arguments. As pointed out above, the correct fix is to use a factory function. --
[Issue 11195] Error messages not suppressed in __traits(compiles,...) for template instantiation nested in aggregate
https://issues.dlang.org/show_bug.cgi?id=11195 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Simen Kjaeraas --- This has apparently been solved some time in the last 4 years. --
