[Issue 20616] Error: undefined identifier __dollar
https://issues.dlang.org/show_bug.cgi?id=20616 RazvanN changed: What|Removed |Added Keywords||bootcamp, trivial CC||razvan.nitu1...@gmail.com --
[Issue 20617] New: There is no support for copying hashmaps in Druntime / Phobos
https://issues.dlang.org/show_bug.cgi?id=20617
Issue ID: 20617
Summary: There is no support for copying hashmaps in Druntime /
Phobos
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
-
void main()
{
int[int] map1 = [1:1, 2:2, 3:3];
int[int] map2;
map2.copy(map1); // ?
}
-
I am not asking for special syntax. Stuff like 'map2 = map1[]` would look cool,
but it's outside the scope here.
There should be `copy` functionality implemented somewhere in Druntime /
Phobos, it's not ideal that we have to write this code manually such as:
-
map1.byKeyValue.each!(pair => map2[pair.key] = pair.value);
-
--
[Issue 18011] core.sys.condition cannot be used as shared
https://issues.dlang.org/show_bug.cgi?id=18011 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @tom-tan updated dlang/druntime pull request #2943 "Add shared methods to Condition" fixing this issue: - Fix Issue 18011 - core.sys.condition cannot be used as shared https://github.com/dlang/druntime/pull/2943 --
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #12 from Adam D. Ruppe ---
(In reply to Steven Schveighoffer from comment #9)
> Except this is not the problem. The CTFE part DOES compile.
h, it is the problem that brought me to this bug.
private string makefoo() {
if(__ctfe) {
string a = "b";
a ~= "c\0";
return a;
}
assert(0);
}
enum foo = makefoo();
extern(C) int main() {
import core.stdc.stdio;
printf("%s", foo.ptr);
return 0;
}
Here that private function is obviously intended to be CTFE only - the
`private` and `if(__ctfe)` make that extremely clear to a human reader, but the
compiler doesn't get the hint.
We could also do a like `pragma(ct_only)` maybe just I was hoping this pattern
would work since it is in the existing language. But nope :(
--
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #11 from Steven Schveighoffer ---
(In reply to ZombineDev from comment #5)
> I guess the trickiest problem to solve is what to do about is(typeof({ code;
> })) and __traits(compiles, { code; }). Allowing those constructs to yield
> true while containing non-betterc code would lead to logical contradictions.
> Disallowing betterc code in such speculative contexts, while allowing it in
> CTFE context would be strange.
When trying to test stuff surrounding this, I'll note that a betterC error
seems to kill the compilation when used inside __traits(compiles).
This prints nothing and produces no binary:
extern(C) void main()
{
int[] arr;
pragma(msg, __traits(compiles, arr.idup));
}
--
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #10 from Steven Schveighoffer ---
Ooooh, I just had an idea. Consider the template that is causing issues _dup.
What if we did this:
version(D_BetterC) extern(C) void _dup_UNAVAILABLE_IN_BETTERC();
private U[] _dup(T, U)(T[] a) // pure nothrow depends on postblit
{
if (__ctfe)
{ /* ctfe code */ }
version(D_BetterC) {
_dup_UNAVAILABLE_IN_BETTERC();
return U[].init;
}
else:
// normal implementation that uses typeid
}
This defers the error to the linker, but with the message identifying which
function is causing the problem. We can probably make an easy mixin to do this
wherever needed.
In essence this is a compiler error, with a "funky" but albeit legible message.
But this does change idup to return true for __traits(compiles). Is that a
problem? I'd say no. Use the version(D_BetterC) instead of __traits(compiles).
Aaand, it doesn't work. Using a template at compile time for some reason makes
the compiler want to link in the symbol. I think there is no way to make this
work unless the compiler is smarter about what it used at compile time vs.
runtime.
--
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #9 from Steven Schveighoffer ---
(In reply to Adam D. Ruppe from comment #8)
> My view is that the code compiles just fine. Just without druntime linked in
> or generated typeinfo, or whatever it depends on at run time, it will not
> link.
>
> The -betterC switch tries to detect these these would-be linker errors and
> report them ahead of time, in the compile step, for more consistent and
> user-friendly errors.
Right, this is my view too.
> Since an `if(__ctfe)` branch (or `mixin` or `pragma(msg)` or any other
> unambiguously* compile-time only area) is never actually involved in code
> generation, that linker error will never actually happen... and the compiler
> *should* know that and not cause the ahead-of-time compile error eiter.
Except this is not the problem. The CTFE part DOES compile. It's the part
that's outside that doesn't (in fact typeid(x) does not compile during CTFE).
So how do you "compile" that, and only allow it to run at compile time? That's
why this is hard.
Any solution for detecting druntime usage is not going to be perfect. For
example, this doesn't have compile errors but linker errors (with -betterC):
import core.thread;
import core.time;
extern(C) void main()
{
Thread.sleep(1.seconds);
}
And of course, __traits(compiles) is going to say YES to this. So it is indeed
a gray area.
--
[Issue 9792] length field of a const SortedRange
https://issues.dlang.org/show_bug.cgi?id=9792
Ali Cehreli changed:
What|Removed |Added
CC||acehr...@yahoo.com
--- Comment #3 from Ali Cehreli ---
I ran into this in a post condition code:
import std.algorithm;
auto foo()
out (result; result.length == 1) { // <-- ERROR
return [ 0 ].sort;
}
void main() {
}
Error: mutable method `std.range.SortedRange!(int[], "a <
b").SortedRange.length` is not callable using a `const` object
Consider adding `const` or `inout` to std.range.SortedRange!(int[], "a <
b").SortedRange.length
Ali
--
[Issue 20616] New: Error: undefined identifier __dollar
https://issues.dlang.org/show_bug.cgi?id=20616
Issue ID: 20616
Summary: Error: undefined identifier __dollar
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: elpenguin...@gmail.com
```
void f() {
struct X {
auto opSlice(size_t a, size_t b) { return ""; }
}
auto x = X()[0 .. $];
}
```
The error is technically correct, but not exactly helpful. __dollar is an
implementation detail that should not be exposed to the user. I would expect
something more along the lines of "Error: no $ operator overload for type X".
--
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268 --- Comment #8 from Adam D. Ruppe --- My view is that the code compiles just fine. Just without druntime linked in or generated typeinfo, or whatever it depends on at run time, it will not link. The -betterC switch tries to detect these these would-be linker errors and report them ahead of time, in the compile step, for more consistent and user-friendly errors. Since an `if(__ctfe)` branch (or `mixin` or `pragma(msg)` or any other unambiguously* compile-time only area) is never actually involved in code generation, that linker error will never actually happen... and the compiler *should* know that and not cause the ahead-of-time compile error eiter. * __traits(compiles) (and is(typeof())) is a grey area. Technically it isn't generating code at all and thus should not generate a linker error, and thus not generate the betterC error but given how it is used in practice I think it should assume the stuff inside WILL be used for codegen and thus return false in these cases. But when in doubt, I say `-betterC` should aim to give the same end result as `-defaultlib=` just with compile errors instead of linker undefined symbol errors. --
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #7 from Steven Schveighoffer ---
(In reply to ZombineDev from comment #5)
> I guess the trickiest problem to solve is what to do about is(typeof({ code;
> })) and __traits(compiles, { code; }). Allowing those constructs to yield
> true while containing non-betterc code would lead to logical contradictions.
> Disallowing betterc code in such speculative contexts, while allowing it in
> CTFE context would be strange.
This is a good point. CTFE is hard because it still needs to compile, even
though in this case you won't actually run that code.
I would say that functions that are not going into the object symbol table can
be compiled and run for CTFE only. If you do try to refer to that symbol during
runtime, then throw the error.
I don't know how hard this is to do, but it seems possible.
possibly another answer is to revert the binding to druntime idup in betterC
mode (obviously this worked before).
--
[Issue 20615] GC spinlock crash
https://issues.dlang.org/show_bug.cgi?id=20615 kinke changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from kinke --- This has probably been fixed in more recent versions, see their changelogs. --
[Issue 20615] New: GC spinlock crash
https://issues.dlang.org/show_bug.cgi?id=20615 Issue ID: 20615 Summary: GC spinlock crash Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: mrsmit...@yandex.ru Thread 2 received signal SIGSEGV, Segmentation fault. (gdb) backtrace #0 0x77ddf242 in do_lookup_x ( undef_name=undef_name@entry=0x77678b0f "_D4core6atomic__T10atomicLoadVEQBdQBb11MemoryOrderi0TmZQBmFNaNbNiNfKOxmZm", new_hash=new_hash@entry=447189232, old_hash=old_hash@entry=0x77fe2080, ref=0x774feda0, result=result@entry=0x77fe2090, scope=0x77ffe428, i=0, version=0x0, flags=5, skip=0x0, type_class=1, undef_map=0x77ff6000) at dl-lookup.c:338 #1 0x77de01ef in _dl_lookup_symbol_x ( undef_name=0x77678b0f "_D4core6atomic__T10atomicLoadVEQBdQBb11MemoryOrderi0TmZQBmFNaNbNiNfKOxmZm", undef_map=0x77ff6000, ref=ref@entry=0x77fe2128, symbol_scope=0x77ff6358, version=0x0, type_class=type_class@entry=1, flags=5, skip_map=) at dl-lookup.c:813 #2 0x77de4ec3 in _dl_fixup (l=, reloc_arg=) at ../elf/dl-runtime.c:112 #3 0x77dec70a in _dl_runtime_resolve_xsave () at ../sysdeps/x86_64/dl-trampoline.h:125 #4 0x779c9755 in core.internal.spinlock.SpinLock.lock() shared () from /home/user/dlang/dmd-2.087.1/linux/lib64/libphobos2.so.0.87 #5 0x779d7209 in _D2gc4impl12conservativeQw3Gcx__T11ToScanStackTSQBuQBuQBsQCdQBi__T9ScanRangeVbi0ZQpZQBz9popLockedMFNbNiKQCfZb () from /home/user/dlang/dmd-2.087.1/linux/lib64/libphobos2.so.0.87 #6 0x779da240 in _D2gc4impl12conservativeQw3Gcx__T4markVbi0Vbi1ZQoMFNbNlSQCcQCcQCaQClQBq__T9ScanRangeVbi0ZQpZv () from /home/user/dlang/dmd-2.087.1/linux/lib64/libphobos2.so.0.87 #7 0x779da5ac in _D2gc4impl12conservativeQw3Gcx__T21pullFromScanStackImplVbi0ZQBcMFNbZv () from /home/user/dlang/dmd-2.087.1/linux/lib64/libphobos2.so.0.87 #8 0x779d4a39 in _D2gc4impl12conservativeQw3Gcx14scanBackgroundMFNbZv () from /home/user/dlang/dmd-2.087.1/linux/lib64/libphobos2.so.0.87 #9 0x779c1acf in _D4core6thread20createLowLevelThreadFNbNiDFNbZvkDFNbZvZ20thread_lowlevelEntryUNbPvZQd () from /home/user/dlang/dmd-2.087.1/linux/lib64/libphobos2.so.0.87 #10 0x772776db in start_thread (arg=0x77fe5700) at pthread_create.c:463 #11 0x765de88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Happens while running lots of unittests at random moments, sometimes it doesn't crash at all. --
[Issue 20589] typeof may give wrong result in case of classes defining `opCall` operator
https://issues.dlang.org/show_bug.cgi?id=20589 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #7398 "Fix issue 20589 - typeof may give wrong result in case of classes defining `opCall` operator" was merged into master: - 7ffdfef3f75d521cc7b0b2659e438f501f263ca1 by drug007: Fix issue 20589 - typeof may give wrong result in case of classes defining `opCall` operator - e4959d4777be74a426aa6d8c58abc5308a62b92b by drug007: Test for issue 20589 https://github.com/dlang/phobos/pull/7398 --
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
--- Comment #6 from Adam D. Ruppe ---
I think my proposal would be that *specifically* the `if(__ctfe)` construct
overrides the betterC checks, since that can be easily factored out.
Just like how we can write
---
int* do_something() {
if(__ctfe) {
return new int;
} else {
return cast(int*) malloc(int.sizeof);
}
}
enum e = *do_something();
---
today (which works in real D, including without linking druntime btw), which
bypasses the normal "malloc cannot be evaluated at compile time), we could
conceivably use it in the other direction to allow something in a CT context
that isn't allowed in a RT context.
I'm not sure how to write that in spec language... it might be able to just say
specifically that betterC's restrictions do not apply inside that specific ast
node and like specifically hack the hack that is betterC.
I think that would be fine with `__traits(compiles)` as well. The `if(__ctfe)`
switch keeps everything compiling the same way - it is specifically a runtime
branch in terms of formal semantics. So the compiles thing passes because that
if branch is encapsulated still.
--
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
ZombineDev changed:
What|Removed |Added
CC||petar.p.ki...@gmail.com
--- Comment #5 from ZombineDev ---
I guess the trickiest problem to solve is what to do about is(typeof({ code;
})) and __traits(compiles, { code; }). Allowing those constructs to yield true
while containing non-betterc code would lead to logical contradictions.
Disallowing betterc code in such speculative contexts, while allowing it in
CTFE context would be strange.
--
[Issue 20614] CTFE supports typeid(stuff).name but not classinfo.name
https://issues.dlang.org/show_bug.cgi?id=20614 Basile-z changed: What|Removed |Added Summary|CTFE supports |CTFE supports |typid(stuff).name but not |typeid(stuff).name but not |classinfo.name |classinfo.name --
[Issue 20614] New: CTFE supports typid(stuff).name but not classinfo.name
https://issues.dlang.org/show_bug.cgi?id=20614
Issue ID: 20614
Summary: CTFE supports typid(stuff).name but not classinfo.name
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: CTFE
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
This commit https://github.com/dlang/dmd/pull/10796, adds support for
retireving the dynamic class name at compile time. but it only works with
typeid and not classinfo, which should be supported too since therey are the
same thing.
---
string classname(Object o)
{
return typeid(o).name;
}
string classnameAlt(Object o)
{
return o.classinfo.name;
}
class Panzer {}
class Tiger : Panzer {}
static assert (() {
Panzer p = new Tiger(); return classname(p);
} () == "Tiger"); // OK
static assert (() {
Panzer p = new Tiger(); return classnameAlt(p);
} () == "Tiger"); // NG
---
--
[Issue 20613] String switch in -betterC fails for 7+ labels
https://issues.dlang.org/show_bug.cgi?id=20613 --- Comment #2 from Steven Schveighoffer --- (In reply to Simen Kjaeraas from comment #0) > Testing indicates the whole anonymous lambda dance used there could be > replaced with > static immutable cases = [caseLabels]; Indeed, I would think that a valid solution. The caseLabels are passed at compile time, so I don't see why they would need to be idup'd. I'm not sure why Martin did it the way he did. I'll ask him. --
[Issue 20613] String switch in -betterC fails for 7+ labels
https://issues.dlang.org/show_bug.cgi?id=20613 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=19268 --
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=20613 --
[Issue 20613] String switch in -betterC fails for 7+ labels
https://issues.dlang.org/show_bug.cgi?id=20613 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- The issue is that the betterC restrictions are being applied during CTFE. I would say that this will be fixed as soon as issue 19268 is fixed. I would say this is really a duplicate. But this use case is important. --
[Issue 20613] New: String switch in -betterC fails for 7+ labels
https://issues.dlang.org/show_bug.cgi?id=20613
Issue ID: 20613
Summary: String switch in -betterC fails for 7+ labels
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
First reported here:
https://forum.dlang.org/post/ptwcucsmyvjklxags...@forum.dlang.org
When compiling with -betterC, switches over strings fail with 7 or more cases,
as in this example:
extern(C) void main()
{
auto s = "F";
final switch(s)
{
case "A": break;
case "B": break;
case "C": break;
case "D": break;
case "E": break;
case "F": break;
case "G": break;
}
}
Which gives this error message:
dmd2\windows\bin\..\..\src\druntime\import\object.d(2981): Error: TypeInfo
cannot be used with -betterC
The reason can be found on this line:
https://github.com/dlang/druntime/blob/e018a72084e54ecc7466e97c96e4557b96b7f905/src/core/internal/switch_.d#L67
, which was added in this commit:
https://github.com/dlang/druntime/commit/fa665f6618af7dbc09ed5ba1333f385017b7ece8
Testing indicates the whole anonymous lambda dance used there could be replaced
with
static immutable cases = [caseLabels];
--
[Issue 20609] Disabled and deprecated functions show up as candidate
https://issues.dlang.org/show_bug.cgi?id=20609 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @Geod24 created dlang/dmd pull request #10838 "Fix issue 20609 - Disabled and deprecated functions show up as candidate" fixing this issue: - Fix issue 20609 - Disabled and deprecated functions show up as candidate Do not show disabled functions as candidate or hints. Only show deprecated functions when inside a deprecated scope. https://github.com/dlang/dmd/pull/10838 --
[Issue 20612] New: alias overload set cause mixin overload function strange behavior
https://issues.dlang.org/show_bug.cgi?id=20612
Issue ID: 20612
Summary: alias overload set cause mixin overload function
strange behavior
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: yunw...@msn.com
import core.stdc.stdio;
class T {
void test() {
printf("t\n");
}
}
class T1 : T {
alias T.test test;
mixin Foo;
}
template Foo() {
override void test() {
printf("t1\n");
}
}
class T2 : T1 {
override void test() {
printf("t2\n");
super.test();
}
}
void main()
{
auto t2 = new T2;
t2.test(); //output t2, t
auto t1 = new T1;
t1.test(); //output t1
}
--
