[Issue 11864] std.variant.Variant doesn't work with CTFE
https://issues.dlang.org/show_bug.cgi?id=11864
Norm Rowtree changed:
What|Removed |Added
CC||norm.rowt...@gmail.com
--- Comment #2 from Norm Rowtree ---
I get pretty much the same error reported using the code snippet below and DMD
D Compiler v2.084.0
struct S {
Variant v = Variant(10);
}
void main() {auto s = S();}
dmd2/linux/bin64/../../src/phobos/std/variant.d(661): Error: memcpy cannot be
interpreted at compile time, because it has no available source code
Error: cannot interpret at compile time
I don't need this evaluated at compile time, I just want a default value when
the struct is instantiated at runtime.
Thanks,
Norm
--
[Issue 8062] UFCS and operator overloading
https://issues.dlang.org/show_bug.cgi?id=8062 Basile-z changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |INVALID --- Comment #7 from Basile-z --- Yes you're right. Please OP reopen with a better example in case the operator was supposed to be a member func. --
[Issue 7977] FormatString grammar is incomplete
https://issues.dlang.org/show_bug.cgi?id=7977 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution|--- |WORKSFORME --- Comment #1 from hst...@quickfur.ath.cx --- Appears to have been fixed in the latest docs (https://dlang.org/phobos-prerelease/std_format#.formattedWrite). %(...%) is now separately defined, and does not allow arbitrary modifiers like width or positional arguments. --
[Issue 8062] UFCS and operator overloading
https://issues.dlang.org/show_bug.cgi?id=8062 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #6 from hst...@quickfur.ath.cx --- Correct me if I'm wrong, but according to spec (https://dlang.org/spec/operatoroverloading.html), operator overloading only works for member functions, not for module-level functions. So UFCS wouldn't apply in this case. --
[Issue 8131] Delegate type inference with templates is absolutely *horrible*
https://issues.dlang.org/show_bug.cgi?id=8131 --- Comment #3 from hst...@quickfur.ath.cx --- Still happens on git HEAD (v2.084.0-395-gcb3a72613). --
[Issue 8184] problem with tuple argument deduction
https://issues.dlang.org/show_bug.cgi?id=8184 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Tested on latest DMD (v2.084.0-395-gcb3a72613). Could not reproduce problem. Please provide more details, what does it mean "does not work"? Compile error? Runtime error? Wrong semantics? Also, please provide a full compilable/runnable code, since from the given code it's not clear which instantiation parameters causes it to fail. --
[Issue 19580] [non-DMD] std.random seed bootstrap: don't count on reading an uninitialized variable being treated as an ordinary read
https://issues.dlang.org/show_bug.cgi?id=19580 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution|--- |FIXED --- Comment #2 from hst...@quickfur.ath.cx --- The PR appears to have been merged, so closing this. Please reopen if there still remains further associated issues to be fixed. --
[Issue 19653] Memory addresses in stacktraces for x86-64 ELFs are only 4 bytes long and don't fall on instruction boundary
https://issues.dlang.org/show_bug.cgi?id=19653 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from ki...@gmx.net --- The address truncation would be fixed in https://github.com/dlang/druntime/pull/2151, which doesn't find any reviewer. --
[Issue 19656] D compiler fails to resolve circular module dependency when modules are compiled separately
https://issues.dlang.org/show_bug.cgi?id=19656 --- Comment #1 from Puneet Goel --- Also see related bug https://issues.dlang.org/show_bug.cgi?id=19657 --
[Issue 19657] D compiler fails to resolve circular module dependency when modules are compiled together
https://issues.dlang.org/show_bug.cgi?id=19657 --- Comment #1 from Puneet Goel --- Also see https://issues.dlang.org/show_bug.cgi?id=19656 --
[Issue 19657] New: D compiler fails to resolve circular module dependency when modules are compiled together
https://issues.dlang.org/show_bug.cgi?id=19657 Issue ID: 19657 Summary: D compiler fails to resolve circular module dependency when modules are compiled together Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: pun...@coverify.org Created attachment 1731 --> https://issues.dlang.org/attachment.cgi?id=1731=edit Tar Gzipped code Test case attached as tar gzipped file. Related to bug 19656. But here the bug appears when the modules are compiled together in a particular order. No error when compiling the modules separately. $ for i in *.d; do dmd -c $i; done # compiles without issue $ dmd -c seq.d foo.d frop.d pol.d trump.d bar.d baz.d # no issue $ dmd -c foo.d frop.d pol.d trump.d bar.d baz.d seq.d frop.d(5): Error: function bool frop.frop.func(foo rhs, bar bee) does not override any function, did you mean to override bool foo.foo.func(foo rhs, bar bee)? --
[Issue 19656] New: D compiler fails to resolve circular module dependency when modules are compiled separately
https://issues.dlang.org/show_bug.cgi?id=19656 Issue ID: 19656 Summary: D compiler fails to resolve circular module dependency when modules are compiled separately Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: pun...@coverify.org Created attachment 1730 --> https://issues.dlang.org/attachment.cgi?id=1730=edit Tar Gzipped code Tar gzipped file is attached. To reproduce the bug, untar and compile foo.d. Note that when all files/modules are compiled together, the compiler does not give any error. This is what I get: $ dmd -c foo.d fred.d(4): Error: function void fred.qux!(bar).qux.thunk() does not override any function, did you mean to override void foo.foo.thunk()? fred.d(7): Error: template instance `fred.qux!(bar)` error instantiating --
[Issue 19655] New: DMD generates wrong code for some circular dependencies
https://issues.dlang.org/show_bug.cgi?id=19655 Issue ID: 19655 Summary: DMD generates wrong code for some circular dependencies Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: pun...@coverify.org Created attachment 1729 --> https://issues.dlang.org/attachment.cgi?id=1729=edit Tar gzipped test case Code attached. To reproduce the bug, untar and "make run" on a linux box. Note that wrong code is generated only when files/modules are compiled separately and then linked into an executable. That is how the included makefile compiles. More on this thread on Dlang Forum --> https://forum.dlang.org/thread/oqdzzgcyuvberlzur...@forum.dlang.org When the exeuctable is run, I get: core.exception.AssertError@grault.d(6): func1 was never called ??:? [0x4148b0] ??:? [0x4190ca] ??:? [0x4063ed] ??:? [0x402aa9] ??:? [0x4023c3] ??:? [0x402367] ??:? [0x40229f] ??:? [0x40608f] ??:? [0x405f87] ??:? [0x402324] ??:? __libc_start_main [0x7f96e3d2d82f] ??:? [0x402188] makefile:12: recipe for target 'run' failed make: *** [run] Error 1 --
[Issue 19654] [REG master] cannot have final methods in objc interfaces
https://issues.dlang.org/show_bug.cgi?id=19654 --- Comment #1 from Jacob Carlborg --- The error message is: Error: function `main.Bar.foo` function body only allowed in `final` functions in interface `Bar` --
[Issue 19654] New: [REG master] cannot have final methods in objc interfaces
https://issues.dlang.org/show_bug.cgi?id=19654
Issue ID: 19654
Summary: [REG master] cannot have final methods in objc
interfaces
Product: D
Version: D2
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: d...@me.com
The following code compiles successfully with DMD 2.084.0 but fails with
master:
extern (Objective-C)
interface Bar
{
final void foo() @selector("foo") {}
}
--
[Issue 19618] Incorrect conversion of function returning `typeof(null)` to function returning an associative array
https://issues.dlang.org/show_bug.cgi?id=19618 Seb changed: What|Removed |Added Status|NEW |RESOLVED CC||greeen...@gmail.com Resolution|--- |FIXED --
[Issue 19653] New: Memory addresses in stacktraces for x86-64 ELFs are only 4 bytes long and don't fall on instruction boundary
https://issues.dlang.org/show_bug.cgi?id=19653
Issue ID: 19653
Summary: Memory addresses in stacktraces for x86-64 ELFs are
only 4 bytes long and don't fall on instruction
boundary
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: trivial
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johannes.riec...@gmail.com
I compile the file stacktrace.d: void main(){assert(false);} with ASLR turned
off and when running I get:
core.exception.AssertError@stacktrace.d(2): Assertion failure
??:? _d_assertp [0x55586ed8]
??:? _Dmain [0x55586e20]
objdump -t stacktrace|grep _Dmain gives
00032e0c wF .text 0019 _Dmain
And if I run gdb -q -nx -ex start -ex 'disas /rs _Dmain' -ex q stacktrace:
...
Dump of assembler code for function _Dmain:
0x55586e0c <+0>: 55 push %rbp
0x55586e0d <+1>: 48 8b ecmov%rsp,%rbp
=> 0x55586e10 <+4>: be 02 00 00 00 mov$0x2,%esi
0x55586e15 <+9>: 48 8d 3d 44 c0 02 00lea0x2c044(%rip),%rdi
# 0x555b2e60 <_TMP0>
0x55586e1c <+16>:e8 47 00 00 00 callq 0x55586e68
<_d_assertp>
0x55586e21 <+21>:31 c0 xor%eax,%eax
0x55586e23 <+23>:5d pop%rbp
0x55586e24 <+24>:c3 retq
So even if the first two 0x55 bytes were just truncated off, 0x...86e20 given
in the stack trace doesn't match the start of an instruction.
--
