[Issue 24566] condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22646 --
[Issue 24566] New: condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566
Issue ID: 24566
Summary: condition that starts with runtime value and uses
compile time array does not short circuit
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
If I mix a runtime and compile time expression in a condition, short circuiting
doesn't prevent a compile-time bounds check for constant folded arrays.
```d
enum a = true;
bool b = true;
enum str = "a";
if(a && str.length > 1 && str[1] == 'a') {} // ok
if(b && str.length > 1 && str[1] == 'a') {} // compiler error
if(!b && str.length > 1 && str[1] == 'a') {} // compiler error
if(str.length > 1 && b && str[1] == 'a') {} // ok
```
The error is:
Error: string index 1 is out of bounds [0 .. 1]
If the runtime condition is not first, then it compiles.
Note that even if the runtime condition is false and should short circuit the
whole thing, the compiler still errors.
As far as I can tell, this has always been the case, so not a regression.
Though a related issue might be issue 22646.
--
[Issue 24536] C runtime constructor/destructor pragma should not be on an exported symbol
https://issues.dlang.org/show_bug.cgi?id=24536 --- Comment #1 from Richard Cattermole --- Another confirmation that it is not required for Linux https://stackoverflow.com/a/32701238 --
[Issue 24536] New: C runtime constructor/destructor pragma should not be on an exported symbol
https://issues.dlang.org/show_bug.cgi?id=24536 Issue ID: 24536 Summary: C runtime constructor/destructor pragma should not be on an exported symbol Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com So apparently the C runtime constructor/destructors should not be exported. This article covers Linux shared libraries and mentions them. https://www.akkadia.org/drepper/dsohowto.pdf It would be good to verify if this is indeed true and ensure the compiler prevents it. --
[Issue 24452] Can't disable coverage at runtime
https://issues.dlang.org/show_bug.cgi?id=24452 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16336 "Add `--DRT-covopt="disable:1"` to suppress writing coverage at runtime." was merged into master: - 212e5cf779a6fa2636a3289f361d468546c7207f by Mathis Beer: Fix Bugzilla issue 24452: Add `--DRT-covopt="disable:1"` to suppress writing coverage at runtime. This is useful if you don't want to rebuild a binary just to have coverage on or off. https://github.com/dlang/dmd/pull/16336 --
[Issue 24452] Can't disable coverage at runtime
https://issues.dlang.org/show_bug.cgi?id=24452 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @FeepingCreature updated dlang/dmd pull request #16336 "Add `--DRT-covopt="disable:1"` to suppress writing coverage at runtime." fixing this issue: - Fix Bugzilla issue 24452: Add `--DRT-covopt="disable:1"` to suppress writing coverage at runtime. This is useful if you don't want to rebuild a binary just to have coverage on or off. https://github.com/dlang/dmd/pull/16336 --
[Issue 24452] New: Can't disable coverage at runtime
https://issues.dlang.org/show_bug.cgi?id=24452 Issue ID: 24452 Summary: Can't disable coverage at runtime Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: default_357-l...@yahoo.de We have a unittest runner built with `-cov`. However, in a separate build step we run it once for every test in isolation. In that case, the test takes 20ms - but merging coverage takes 500ms. (It's a pretty big binary.) It would be good to have a runtime flag to suppress coverage writing. --
[Issue 18788] static arrays with a length specified at runtime should dynamically allocate on the stack
https://issues.dlang.org/show_bug.cgi?id=18788 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #9 from Nick Treleaven --- (In reply to Mike Franklin from comment #5) > Another way of achieving the same result would be to make a `scope`d dynamic > array allocate on the stack For the record, this got implemented in Issue 22306. Probably this can be closed now. --
Re: cannot find source code for runtime library file 'object.d'
denis via Digitalmars-d-learn wrote: On Monday, 20 November 2023 at 07:50:22 UTC, thinkunix wrote: denis via Digitalmars-d-learn wrote: ``` $ zypper install dmd $ dmd main.d Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. config file: /etc/dmd.conf I would say the package has files in the wrong locations. Try the binary from dlang.org: https://downloads.dlang.org/releases/2.x/2.105.3/dmd-2.105.3-0.openSUSE.x86_64.rpm Thank you Scot, I confirm that installing manually does the trick You should open a bug report with OpenSUSE to let them know their official package does not work. Point them to the dlang.org openSUSE package which does work for how to "do it right". scot
Re: cannot find source code for runtime library file 'object.d'
On Monday, 20 November 2023 at 07:50:22 UTC, thinkunix wrote: denis via Digitalmars-d-learn wrote: ``` $ zypper install dmd $ dmd main.d Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. config file: /etc/dmd.conf I would say the package has files in the wrong locations. Try the binary from dlang.org: https://downloads.dlang.org/releases/2.x/2.105.3/dmd-2.105.3-0.openSUSE.x86_64.rpm I'm not familiar with zypper but I'll bet you can install it by: # zypper install ./dmd-2.105.3-0.openSUSE.x86_64.rpm On a RHEL-like distro, this works: # yum install ./pkgname.rpm ... scot Thank you Scot, I confirm that installing manually does the trick Regards Denis
Re: cannot find source code for runtime library file 'object.d'
denis via Digitalmars-d-learn wrote:
```
$ zypper install dmd
$ dmd main.d
Error: cannot find source code for runtime library file 'object.d'
dmd might not be correctly installed. Run 'dmd -man' for
installation instructions.
config file: /etc/dmd.conf
I would say the package has files in the wrong locations.
Try the binary from dlang.org:
https://downloads.dlang.org/releases/2.x/2.105.3/dmd-2.105.3-0.openSUSE.x86_64.rpm
I'm not familiar with zypper but I'll bet you can install it by:
# zypper install ./dmd-2.105.3-0.openSUSE.x86_64.rpm
On a RHEL-like distro, this works:
# yum install ./pkgname.rpm
Just be sure to use your package manager tool (yum, zypper, whatever)
to install the binary so it can later be removed or updated.
More details:
I ran into something similar,'object.d' not found, when trying to
build dmd from source. In the end I grabbed the prebuilt dmd binary
RPM from dlang.org and followed the locations where it placed files,
then everything "just works".
If you have the rpm command, you can run the following to get the file
list without installing it:
$ rpm -qlp pkgname.rpm
If you do not have the rpm command, you can use rpm2cpio to convert the
rpm into a cpio archive, then read it:
$ rpm2cpio pkgname.rpm > pkgname.cpio
$ cpio -itv < pkgname.cpio | more
$ cat /etc/dmd.conf
[Environment32]
DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib -L--export-dynamic -fPIC
[Environment64]
DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib64 -L--export-dynamic -fPIC
Here's what's in my /etc/dmd.conf;
Note there is no 'dlang' subdir in /usr/include, just 'dmd'.
cut here
[Environment32]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import
-L-L/usr/lib -L--export-dynamic -fPIC
[Environment64]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import
-L-L/usr/lib64 -L--export-dynamic -fPIC
cut here
$ ls /usr/include/dlang/dmd
/usr/include/dmd should have two directories: druntime and phobos,
nothing else.
object.d lives here:
/usr/include/dmd/druntime/import/object.d
$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
VERSION="20231006"
$ dmd --version
DMD64 D Compiler v2.105.3
```
Help?
If you decide to build from source, keep in mind you need a D
compiler to build dmd. Either use a binary tarball from dlang.org,
or you have to bootstrap dmd 2.067.1 with a C++ compiler, then
keep upgrading dmd until you get to the version you want. It can be
done and does work, but takes time. Instructions are here:
https://wiki.dlang.org/Building_under_Posix
I'm guessing the person who build the package was thinking they
wanted to allow allow installing mulitple D compilers, all under
/usr/include/dlang, like so:
/usr/include/dlang/{dmd,gdc,ldc2}
and libraries would go under /usr/lib64/dlang/{dmd,gdc,ldc2}.
I made several attempts at this and they failed. Like I said,
follow the locations of the dlang.org prebuilt rpm and it all
just works, or use a binary from dlang.org.
scot
cannot find source code for runtime library file 'object.d'
``` $ zypper install dmd $ dmd main.d Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. config file: /etc/dmd.conf $ cat /etc/dmd.conf ; ; dmd.conf file for dmd ; ; dmd will look for dmd.conf in the following sequence of directories: ; - current working directory ; - directory specified by the HOME environment variable ; - directory dmd resides in ; - /etc directory ; ; Names enclosed by %% are searched for in the existing environment and inserted ; ; The special name %@P% is replaced with the path to this file ; [Environment32] DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib -L--export-dynamic -fPIC [Environment64] DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib64 -L--export-dynamic -fPIC $ ls /usr/include/dlang/dmd $ cat /etc/os-release NAME="openSUSE Tumbleweed" VERSION="20231006" $ dmd --version DMD64 D Compiler v2.105.3 ``` Help?
[Issue 24220] New: Static array of nested struct changes .init value at runtime
https://issues.dlang.org/show_bug.cgi?id=24220
Issue ID: 24220
Summary: Static array of nested struct changes .init value at
runtime
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: snarwin+bugzi...@gmail.com
As of DMD 2.105.3, the following program asserts at runtime:
---
void main()
{
int n;
struct Nested
{
int fun() { return n; }
}
static a = Nested.init;
auto b = Nested.init;
assert(a is b); // ok
static a1 = (Nested[1]).init;
auto b1 = (Nested[1]).init;
assert(a1[0] is b1[0]); // fails
}
---
The error message, with -checkaction=context, is:
---
core.exception.AssertError@bug.d(15): Nested(: 0x0) !is
Nested(: 0x7f8e09158000)
---
A variable initialized with Nested.init will always have a null context
pointer, whether it is initialized at compile time or runtime. However, a
variable initialized with (Nested[1]).init has a null context pointer when
initialized at compile time, and a non-null context pointer when initialized at
runtime.
For the sake of consistency, the context pointer should be null in all cases.
--
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181
--- Comment #8 from Walter Bright ---
For this:
unsigned equ(double x, double y) {
return *(long long *) == *(long long *)
}
The generated code is:
equ:
sub RSP,018h
movq[RSP],XMM0
mov RAX,[RSP]
cmp RAX,RCX <== ARRRGHHH!!
setzAL
movzx RAX,AL
add RSP,018h
ret
The `y` parameter is passed in XMM1, not RCX. The cast to long long has fooled
the code generator.
I suspected something like this was happening, but it took a while to find it.
--
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 --- Comment #7 from mw --- BTW, dmd generate binary also have runtime error with this single file lisp: https://github.com/Robert-van-Engelen/lisp/blob/main/src/lisp.c src$ dmd lisp.c src$ ./lisp lisp unbound define ERR 3 unbound symbol 8020+2000> # dmd -m32 works fine: src$ dmd -m32 lisp.c $ ./lisp lisp null? number? ... defmacro defun 6322+1929> GCC, and LDC2 works fine. --
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 --- Comment #6 from mw --- In the same github repo, there is a equivalent commented .c file (dmd generated binary has the same runtime error): https://github.com/Robert-van-Engelen/tinylisp https://github.com/Robert-van-Engelen/tinylisp/blob/main/src/tinylisp-commented.c and the design doc: https://github.com/Robert-van-Engelen/tinylisp/blob/main/tinylisp.pdf gcc works fine: $ make tinylisp-commented cc tinylisp-commented.c -o tinylisp-commented (env) zhou@joort:~/project/unzip/tinylisp/src$ ./tinylisp-commented tinylisp 930>(+ 3 5) 8 $ dmd tinylisp-commented.c tinylisp-commented.c: Error: module `tinylisp-commented` has non-identifier characters in filename, use module declaration instead $ ln -s tinylisp-commented.c tinylisp_commented.c $ dmd tinylisp_commented.c $ ./tinylisp_commented tinylisp 930>(+ 3 5) ERR # -m32 works confirmed: $ dmd -m32 tinylisp_commented.c $ ./tinylisp_commented tinylisp 930>(+ 3 5) 8 --
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 --- Comment #5 from Walter Bright --- Ah, thanks Dennis! This is very helpful. --
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181
Dennis changed:
What|Removed |Added
CC||dkor...@live.nl
--- Comment #4 from Dennis ---
I tried reducing it with dustmite, but it's still pretty large:
```
int printf();
int sscanf();
char *strcpy();
int strcmp();
long strlen();
unsigned hp, sp = 1024, ATOM, PRIM, CONS = 0x7ffa, NIL;
double cell[1024], nil, tru, err, env;
double box(unsigned t, unsigned i)
{
double x;
*(long *) = (long)t << 48 | i;
return x;
}
unsigned ord(double x) { return *(unsigned *) }
unsigned equ(double x, double y) { return *(unsigned *) == *(long *) }
double atom(char *s)
{
unsigned i = 0;
while (i < hp && strcmp((char *)cell + i, s))
i += 1;
hp += strlen(strcpy((char *)cell + i, s)) + 1;
return box(ATOM, i);
}
double cons(double x, double y)
{
cell[--sp] = x;
cell[--sp] = y;
return box(CONS, sp);
}
double car(double p)
{
return p ? cell[ord(p) + 1] : err;
}
double cdr(double p)
{
return p ? cell[ord(p)] : err;
}
double pair(double v, double x, double e)
{
return cons(cons(v, x), e);
}
double assoc(double v, double e)
{
while (e && !equ(v, car(car(e
e = cdr(e);
return e ? cdr(car(e)) : err;
}
unsigned not(double x) { return x == NIL; }
double f_add(double t)
{
double n;
while (!not(t = cdr(t)))
n += car(t);
return n;
}
struct
{
char *s;
double (*f)();
} prim[] = {
"-", 0,
"+", f_add,
};
double apply(double f, double t)
{
return f ? prim[ord(f)].f(t) : f;
}
double eval(double x, double e)
{
return *(long *) >> 48 == ATOM ? assoc(x, e) : x ? apply(eval(car(x),
e), x) : x;
}
char buf[40], see;
char* input = "(+ 4 4)";
int inputI = 0;
void look()
{
see = input[inputI++];
}
unsigned seeing(char c) { return c ? see <= c : see; }
char get()
{
char c = see;
look();
return c;
}
char scan()
{
int i = 0;
while (seeing(' '))
look();
return buf[i++] = get();
}
double parse();
double list()
{
double x;
return scan() == ')' ? nil : (x = parse(), cons(x, list()));
}
double atomic()
{
double n;
int i;
return sscanf(buf, "%lg%n", , ) ? n : atom(buf);
}
double parse()
{
return *buf == '(' ? list() : atomic();
}
void print(double x)
{
// printf("%016lX\n", *(unsigned long*));
if (x == ATOM)
printf("ERR");
else
printf("%.10lg", x);
}
int main()
{
int i;
for (i = 0; prim[i].s; ++i)
env = pair(atom(prim[i].s), box(PRIM, i), env);
double result = eval((scan(), parse()), env);
print(result);
}
```
This program prints 8 with gcc, but ERR with dmd on linux 64-bit.
--
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 Walter Bright changed: What|Removed |Added Keywords||backend --- Comment #3 from Walter Bright --- Hmm, it does work with -m32, implying a code gen problem. --
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- Unfortunately, it's not a very simple example. It's very dense, compressed code with no comments. So far, I haven't found where the dmd version diverges from the gcc version. I'll look at it some more tomorrow. --
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 --- Comment #1 from mw --- BTW, $ dmd --version DMD64 D Compiler v2.105.0 Copyright (C) 1999-2023 by The D Language Foundation, All Rights Reserved written by Walter Bright And LDC works fine: $ ldc2 -version LDC - the LLVM D compiler (1.34.0): based on DMD v2.104.2 and LLVM 16.0.6 built with LDC - the LLVM D compiler (1.34.0) Default target: x86_64-unknown-linux-gnu Host CPU: znver1 http://dlang.org - http://wiki.dlang.org/LDC $ ./tinylisp tinylisp 930>(+ 2 3) 5 --
[Issue 24181] dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 Basile-z changed: What|Removed |Added Keywords||ImportC --
[Issue 24181] New: dmd compiled tinylisp.c runtime error
https://issues.dlang.org/show_bug.cgi?id=24181 Issue ID: 24181 Summary: dmd compiled tinylisp.c runtime error Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: min...@gmail.com Created attachment 1893 --> https://issues.dlang.org/attachment.cgi?id=1893=edit single file, 99 lines tinylisp.c I'm playing with https://github.com/Robert-van-Engelen/tinylisp/blob/main/src/tinylisp.c single file, 99 lines with GCC: ``` $ make -B tinylisp cc-c -o tinylisp.o tinylisp.c cc tinylisp.o -o tinylisp $ ./tinylisp tinylisp 930>(+ 2 3) 5 ``` wich dmd (importC): ``` $ dmd tinylisp.c # build fine $ ./tinylisp tinylisp 930>(+ 2 3) ERR 930>^C ``` something goes wrong at runtime for such simple example. --
[Issue 24115] No runtime crash on use of a noreturn template argument
https://issues.dlang.org/show_bug.cgi?id=24115 Basile-z changed: What|Removed |Added Resolution|FIXED |INVALID --
[Issue 24115] No runtime crash on use of a noreturn template argument
https://issues.dlang.org/show_bug.cgi?id=24115 Basile-z changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 24115] No runtime crash on use of a noreturn template argument
https://issues.dlang.org/show_bug.cgi?id=24115 Basile-z changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24114 --
[Issue 24115] New: No runtime crash on use of a noreturn template argument
https://issues.dlang.org/show_bug.cgi?id=24115
Issue ID: 24115
Summary: No runtime crash on use of a noreturn template
argument
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
For the following code there's no runtime crash
```
int v(e)()
{
return e + 0;
}
int main()
{
return v!(noreturn)();
}
```
--
Compiling the runtime library
Is it possible to recompile the LDC and GDC runtimes yourself so you can do so with the switches you desire? (eg regarding optimisation, release vs debug build modes.) I think I saw a mention of something to help with this in the LDC docs, GDC would be a different story though. I’d have to get hold of the code first somehow, of course.
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 --- Comment #4 from Walter Bright --- That program also works with Digital Mars C. --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761
--- Comment #3 from Walter Bright ---
This C program works with 64 bit Windows VC:
-
#include
#include
#include
void main()
{
fwprintf(stdout, L"Helláá LDC\n");
fflush(stdout);
}
--
So there's definitely something wrong with the Microsoft version code in
std.stdio.
This is on Windows 7.
--
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- It works with -m32 (the 32 bit OMF output) --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24001 --
[Issue 5862] case statement allows runtime values
https://issues.dlang.org/show_bug.cgi?id=5862 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #8 from Nick Treleaven --- (In reply to Andrej Mitrovic from comment #0) >case y: // <- should not be allowed comment #4: > Strangely, 1.068 (Win32) correctly rejects the code. Also rejected on Linux now: switchmut.d(14): Error: `case` variables have to be `const` or `immutable` --
[Issue 23832] dmd regression 2.103.0 silent error cannot call decode at runtime
https://issues.dlang.org/show_bug.cgi?id=23832 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #15088 "Fix Issue 23832 - dmd regression 2.103.0 silent error cannot call decode at runtime" was merged into master: - 960cd47e01652e7f11bb0a142b6794f86da4ea2e by RazvanN7: Fix Issue 23832 - dmd regression 2.103.0 silent error cannot call decode at runtime https://github.com/dlang/dmd/pull/15088 --
[Issue 23832] dmd regression 2.103.0 silent error cannot call decode at runtime
https://issues.dlang.org/show_bug.cgi?id=23832 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15088 "Fix Issue 23832 - dmd regression 2.103.0 silent error cannot call decode at runtime" fixing this issue: - Fix Issue 23832 - dmd regression 2.103.0 silent error cannot call decode at runtime https://github.com/dlang/dmd/pull/15088 --
[Issue 23832] New: dmd regression 2.103.0 silent error cannot call decode at runtime
https://issues.dlang.org/show_bug.cgi?id=23832
Issue ID: 23832
Summary: dmd regression 2.103.0 silent error cannot call decode
at runtime
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: alphaglosi...@gmail.com
The second static assert below will not trigger, but the first will.
dmd -betterC test.d
```d
void main() {
import std.utf : decode;
size_t i;
string str = "test";
// static assert(0);
dchar c = decode(str, i);
static assert(0);
}
```
No output is given without the first static assert.
--
[Issue 23805] Runtime segmentation fault when destructor access function frame
https://issues.dlang.org/show_bug.cgi?id=23805 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15046 "Fix Issue 23805 - Runtime segmentation fault when destructor access function frame" fixing this issue: - Fix Issue 23805 - Runtime segmentation fault when destructor access function frame https://github.com/dlang/dmd/pull/15046 --
[Issue 23805] Runtime segmentation fault when destructor access function frame
https://issues.dlang.org/show_bug.cgi?id=23805
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #2 from RazvanN ---
Makes sense to me to have it error.
Another incosistency:
void fun(T)()
{
T a;
}
If `fun` is instantiated with DontDestruct you end up with: "Error: cannot
access frame pointer of `test.main.CantDestruct`" at line "T a;". However, if
you replace it with `T a = T.init` it compiles. `T a` and `T a = T.init` are
exactly the same thing.
--
[Issue 23805] Runtime segmentation fault when destructor access function frame
https://issues.dlang.org/show_bug.cgi?id=23805 --- Comment #1 from Mathias LANG --- As Steven Schveighoffer pointed out, this is because the context pointer is `null`. So we should probably disable `.init` for nested structures, or find a way to prevent this mistake. --
[Issue 23805] New: Runtime segmentation fault when destructor access function frame
https://issues.dlang.org/show_bug.cgi?id=23805
Issue ID: 23805
Summary: Runtime segmentation fault when destructor access
function frame
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pro.mathias.l...@gmail.com
```
void main ()
{
size_t destructionCount;
struct CantDestruct {
int value;
~this () { ++destructionCount; }
}
static void test(CantDestruct a) {}
test(CantDestruct.init);
}
```
This crashes with a segfault when running the program.
--
[Issue 20458] CRTP + pass alias to virtual member to mixin = runtime crash
https://issues.dlang.org/show_bug.cgi?id=20458
--- Comment #4 from Basile-z ---
Finally the generic reproduction
```
class Base
{
alias a = Derived.test;
pragma(msg, typeof(a)); // triggers the vtbl corruption
}
class Derived : Base
{
void test(){}
}
void main()
{
(new Derived).test();
}
```
--
[Issue 20458] CRTP + pass alias to virtual member to mixin = runtime crash
https://issues.dlang.org/show_bug.cgi?id=20458
--- Comment #3 from Basile-z ---
The same corruption without the getMember trait:
```
mixin template Impl(T){
alias a = T.test;
pragma(msg, typeof(a)); // launch dsymbolsema and corrupt vtbl
}
class A(T) {
mixin Impl!T;
}
class Foo : A!Foo {
void test() {}
}
void main() {
(new Foo).test();
}
```
--
[Issue 20458] CRTP + pass alias to virtual member to mixin = runtime crash
https://issues.dlang.org/show_bug.cgi?id=20458
--- Comment #2 from Basile-z ---
reduced further
```
mixin template Impl(T){
alias a = __traits(getMember, T, "test");
//alias a = T.test; // no vtbl corruption with this alias
}
class A(T) {
mixin Impl!T;
}
class Foo : A!Foo {
void test() {}
}
void main() {
(new Foo).test();
}
```
--
[Issue 20458] CRTP + pass alias to virtual member to mixin = runtime crash
https://issues.dlang.org/show_bug.cgi?id=20458 Basile-z changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #1 from Basile-z --- With assertions built in DMD your code triggers this : https://github.com/dlang/dmd/blob/498822ec8efb8e2b68e257b01fa1e097ec6e3a88/compiler/src/dmd/dsymbolsem.d#L5261, so the vtbl seems to be started already, probably with "test" but then is rebuild again, without --
[Issue 23638] [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
Re: Deciding one member of iteration chain at runtime
On Friday, 17 February 2023 at 17:42:19 UTC, Ali Çehreli wrote: // Two different steps auto g1 = r.map!((int n) => n * n); auto g2 = r.map!((int n) => n * 10); // The rest of the algoritm auto result = choose(condition, g1, g2) .array; Now that's a handy construct. There's many little goodies in phobos I've yet to learn, thanks for the tip!
Re: Deciding one member of iteration chain at runtime
On Friday, 17 February 2023 at 17:44:20 UTC, H. S. Teoh wrote: Here's an actual function taken from my own code, that returns a different range type depending on a runtime condition, maybe this will help you? Thanks, this was helpful. I keep forgetting to expand my horizons on what can be returned from an auto function. I'm still unlearning C & Java. Cheers,
Re: Deciding one member of iteration chain at runtime
On 2/17/23 09:30, Chris Piker wrote:
> operatorG needs
> to be of one of two different types at runtime
std.range.choose may be useful but I think it requires creating two
variables like g1 and g2 below:
import std.range;
import std.algorithm;
void main(string[] args) {
const condition = (args.length > 1);
// The first part of the algorithm
auto r = iota(10)
.filter!(n => n % 2);
// Two different steps
auto g1 = r.map!((int n) => n * n);
auto g2 = r.map!((int n) => n * 10);
// The rest of the algoritm
auto result = choose(condition, g1, g2)
.array;
}
Ali
Re: Deciding one member of iteration chain at runtime
On Fri, Feb 17, 2023 at 05:30:40PM +, Chris Piker via Digitalmars-d-learn
wrote:
[...]
> In order to handle new functionality it turns out that operatorG needs
> to be of one of two different types at runtime. How would I do
> something like the following:
>
> ```d
> auto virtualG; // <-- probably invalid code, illustrating the idea
> if(runtime_condition)
>virtualG = operatorG1;
> else
>virtualG = operatorG2;
[...]
> ```
> ?
>
> I've tried various usages of `range.InputRangeObject` but haven't been
> able to get the syntax right. Any suggestions on the best way to
> proceed? Maybe the whole chain should be wrapped in InputRangeObject
> classes, I don't know.
[...]
Here's an actual function taken from my own code, that returns a
different range type depending on a runtime condition, maybe this will
help you?
```d
/**
* Expands '@'-directives in a range of strings.
*
* Returns: A range of strings with lines that begin with '@'
* substituted with the contents of the file named by the rest of the
* line.
*/
auto expandFileDirectives(File = std.stdio.File, R)(R args)
if (isInputRange!R && is(ElementType!R : const(char)[]))
{
import std.algorithm.iteration : joiner, map;
import std.algorithm.searching : startsWith;
import std.range : only;
import std.range.interfaces : InputRange, inputRangeObject;
import std.typecons : No;
return args.map!(arg => arg.startsWith('@') ?
cast(InputRange!string) inputRangeObject(
File(arg[1 .. $]).byLineCopy(No.keepTerminator)) :
cast(InputRange!string) inputRangeObject(only(arg)))
.joiner;
}
```
Note that the cast is to a common base class of the two different
subclasses returned by inputRangeObject().
This function is used in the rest of the code as part of a UFCS chain of
ranges.
T
--
Long, long ago, the ancient Chinese invented a device that lets them see
through walls. It was called the "window".
Deciding one member of iteration chain at runtime
Hi D I have a main "loop" for a data processing program that looks much as follows: ```d sourceRange .operatorA .operatorB .operatorC .operatorD .operatorE .operatorF .operatorG .operatorH .copy(destination); ``` Where all `operator` items above are InputRange structs that take an upstream range, and the pipeline really is 9 operations deep. In order to handle new functionality it turns out that operatorG needs to be of one of two different types at runtime. How would I do something like the following: ```d auto virtualG; // <-- probably invalid code, illustrating the idea if(runtime_condition) virtualG = operatorG1; else virtualG = operatorG2; sourceRange .operatorA .operatorB .operatorC .operatorD .operatorE .operatorF .virtualG .operatorH .copy(destination); ``` ? I've tried various usages of `range.InputRangeObject` but haven't been able to get the syntax right. Any suggestions on the best way to proceed? Maybe the whole chain should be wrapped in InputRangeObject classes, I don't know. Thanks,
[Issue 19575] core.cpuid not usable without a runtime
https://issues.dlang.org/show_bug.cgi?id=19575 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dlang Bot --- dlang/dmd pull request #14671 "fix Issue 19575 - core.cpuid not usable without a runtime" was merged into master: - 63efd5f3e093e97733546f1b7c0a85882c316526 by Walter Bright: fix Issue 19575 - core.cpuid not usable without a runtime https://github.com/dlang/dmd/pull/14671 --
Re: Hipreme's #8 Tip of the day - Using custom runtime with dub projects
On Sunday, 22 January 2023 at 18:16:35 UTC, Hipreme wrote: Nope. Those DFLAGS environment variable is used to affect projects such as my dependencies. For example, my dependency needs to be built using my own runtime. The dflags defined in the dub.json only affect the current project, not its dependencies Ah ok, got it, the compiler will fetch them for a whole session no matter what is currently being built. Though this approach will make it harder to anyone who might want to use your project/library if this requirement remains for a user's project.
Re: Hipreme's #8 Tip of the day - Using custom runtime with dub projects
On Sunday, 22 January 2023 at 17:06:13 UTC, evilrat wrote: On Sunday, 22 January 2023 at 16:57:56 UTC, Hipreme wrote: The way to use dub's packages is by using the DFLAGS. With DFLAGS, I can set the import path to my own DRuntime and own std. That way I can make the dependencies behave more or less the same, this is an example of what is being done now: Keep in mind that you'll probably need to setup some env variables such as mine done for making your script a little more portable to other developer's PCs. I would really like if there was a way to define global dflags on dub though. Can't you just use env variable[1] and put into dub dflags like this? https://github.com/Superbelko/ohmygentool/blob/cc75d915a8df8bdc2bba628df305d421151994a1/dub.json#L11 _(note that some of the listed predefines doesn't work in some sections though, a bug maybe?)_ [1] https://dub.pm/package-format-json.html#environment-variables Nope. Those DFLAGS environment variable is used to affect projects such as my dependencies. For example, my dependency needs to be built using my own runtime. The dflags defined in the dub.json only affect the current project, not its dependencies
Re: Hipreme's #8 Tip of the day - Using custom runtime with dub projects
On Sunday, 22 January 2023 at 16:57:56 UTC, Hipreme wrote: The way to use dub's packages is by using the DFLAGS. With DFLAGS, I can set the import path to my own DRuntime and own std. That way I can make the dependencies behave more or less the same, this is an example of what is being done now: Keep in mind that you'll probably need to setup some env variables such as mine done for making your script a little more portable to other developer's PCs. I would really like if there was a way to define global dflags on dub though. Can't you just use env variable[1] and put into dub dflags like this? https://github.com/Superbelko/ohmygentool/blob/cc75d915a8df8bdc2bba628df305d421151994a1/dub.json#L11 _(note that some of the listed predefines doesn't work in some sections though, a bug maybe?)_ [1] https://dub.pm/package-format-json.html#environment-variables
Hipreme's #8 Tip of the day - Using custom runtime with dub projects
I have been working with WebAssembly for at least 1 entire month into getting my entire Game Engine and DRuntime ported to it. As I'm almost reaching the point of the new announcement, I come here to show how I've done DUB's dependency compatibility with a custom runtime. The way to use dub's packages is by using the DFLAGS. With DFLAGS, I can set the import path to my own DRuntime and own std. That way I can make the dependencies behave more or less the same, this is an example of what is being done now: ``` set DFLAGS=-I=%HIPREME_ENGINE%/modules/d_std/source ^ -I=%HIPREME_ENGINE%/build/wasm/runtime/webassembly/arsd-webassembly ^ -preview=shortenedMethods ^ -L-allow-undefined ^ -fvisibility=hidden ^ -d-version=CarelessAlocation dub build --build=debug -c wasm --arch=wasm32-unknown-unknown-wasm ``` So, when dub tried to build their dependencies, your custom runtime overrides D's default ones. In that case I'm overriding both D std and D core/** and object.d Keep in mind that you'll probably need to setup some env variables such as mine done for making your script a little more portable to other developer's PCs. I would really like if there was a way to define global dflags on dub though.
[Issue 23638] [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638 --- Comment #4 from RazvanN --- (In reply to Jack Stouffer from comment #2) > (In reply to RazvanN from comment #1) > > Unfortunately, the problem comes from the fact that the hook uses typeid > > internally. `dup` is just a normal template so the compiler does not give it > > any special treatment. The source of this is that dup uses internally typeid > > to pass a Typeinfo to the newarray hook (which currently is not > > templatized). Once newarray is templatized and Typeinfo is not needed > > anymore, the problem will disappear. > > > > So, I guess, the real solution in this case is to templatize the > > _d_new_array hook. > > Sounds like the actual root cause is that use of typeid in betterC mode > doesn't result in a trace. People have been trying to template-ize druntime > for like seven years so fixing the typeid problem is more likely to bear > fruit. Also, the typeid problem is just at the surface, the underlying issue is that a function that receives a Typeinfo object is called (and typeid is used to get the underling Typeinfo). We can get around this only by templating that function (which is a compiler hook). --
[Issue 23638] [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638 --- Comment #3 from RazvanN --- (In reply to Jack Stouffer from comment #2) > (In reply to RazvanN from comment #1) > > Unfortunately, the problem comes from the fact that the hook uses typeid > > internally. `dup` is just a normal template so the compiler does not give it > > any special treatment. The source of this is that dup uses internally typeid > > to pass a Typeinfo to the newarray hook (which currently is not > > templatized). Once newarray is templatized and Typeinfo is not needed > > anymore, the problem will disappear. > > > > So, I guess, the real solution in this case is to templatize the > > _d_new_array hook. > > Sounds like the actual root cause is that use of typeid in betterC mode > doesn't result in a trace. People have been trying to template-ize druntime > for like seven years so fixing the typeid problem is more likely to bear > fruit. Actually, a lot of progress has been recently and a lot of hooks have already been templated: https://www.youtube.com/watch?v=dsa8GWL6TUo_channel=TheDLanguageFoundation . I have highs hopes that 2023 will be the year when we finally achieve this. --
[Issue 23638] [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638 --- Comment #2 from Jack Stouffer --- (In reply to RazvanN from comment #1) > Unfortunately, the problem comes from the fact that the hook uses typeid > internally. `dup` is just a normal template so the compiler does not give it > any special treatment. The source of this is that dup uses internally typeid > to pass a Typeinfo to the newarray hook (which currently is not > templatized). Once newarray is templatized and Typeinfo is not needed > anymore, the problem will disappear. > > So, I guess, the real solution in this case is to templatize the > _d_new_array hook. Sounds like the actual root cause is that use of typeid in betterC mode doesn't result in a trace. People have been trying to template-ize druntime for like seven years so fixing the typeid problem is more likely to bear fruit. --
[Issue 23638] [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- Unfortunately, the problem comes from the fact that the hook uses typeid internally. `dup` is just a normal template so the compiler does not give it any special treatment. The source of this is that dup uses internally typeid to pass a Typeinfo to the newarray hook (which currently is not templatized). Once newarray is templatized and Typeinfo is not needed anymore, the problem will disappear. So, I guess, the real solution in this case is to templatize the _d_new_array hook. --
[Issue 23638] [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638 Jack Stouffer changed: What|Removed |Added Keywords||betterC, diagnostic --
[Issue 23638] New: [betterC] Better Error Message For Runtime Usage
https://issues.dlang.org/show_bug.cgi?id=23638
Issue ID: 23638
Summary: [betterC] Better Error Message For Runtime Usage
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: j...@jackstouffer.com
Consider
extern (C) int main ()
{
auto s = "a".idup;
return 0;
}
This gives the following
src/druntime/import/object.d(3822): Error: `TypeInfo` cannot be used with
-betterC
This is a trivial example, but when the library is 30 kloc it's a bit harder to
track down the offending code from this message. Especially since it doesn't
even tell you which runtime function is the problem.
I think the easiest thing to do would be to just add a stack trace like the
ones in the error messages for bad template instantiations. Something like
src/druntime/import/object.d(3822): Error: `TypeInfo` cannot be used with
-betterC
Instantiated from here: main.d(3)
It would be nice to have but not necessary to say the name of the runtime
function that's attempted to be used.
src/druntime/import/object.d(3822): Error: `TypeInfo` cannot be used with
-betterC
In function dup defined on object.d(3820)
Instantiated from here: main.d(3)
--
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 --- Comment #9 from Dlang Bot --- dlang/dmd pull request #14815 "Merge stable" was merged into master: - ba04b29d9e88de69e0ac8fb021410f8d509c73f5 by Walter Bright: fix Issue 20520 - Runtime segfault when taking typeid of a class instanciated within an enum https://github.com/dlang/dmd/pull/14815 --
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 --- Comment #8 from Dlang Bot --- @dkorpel updated dlang/dmd pull request #14815 "Merge stable" fixing this issue: - fix Issue 20520 - Runtime segfault when taking typeid of a class instanciated within an enum https://github.com/dlang/dmd/pull/14815 --
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dlang Bot --- dlang/dmd pull request #14777 "fix Issue 20520 - Runtime segfault when taking typeid of a class inst…" was merged into stable: - a8f32669c453dd524fa157382a0be870088bde53 by Walter Bright: fix Issue 20520 - Runtime segfault when taking typeid of a class instanciated within an enum https://github.com/dlang/dmd/pull/14777 --
[Issue 19575] core.cpuid not usable without a runtime
https://issues.dlang.org/show_bug.cgi?id=19575 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @WalterBright updated dlang/dmd pull request #14671 "fix Issue 19575 - core.cpuid not usable without a runtime" fixing this issue: - fix Issue 19575 - core.cpuid not usable without a runtime https://github.com/dlang/dmd/pull/14671 --
[Issue 23602] Reimplement associative arrays on runtime
https://issues.dlang.org/show_bug.cgi?id=23602 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 23602] New: Reimplement associative arrays on runtime
https://issues.dlang.org/show_bug.cgi?id=23602 Issue ID: 23602 Summary: Reimplement associative arrays on runtime Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: msnmanc...@hotmail.com Current D Runtime Associative Array is pretty buggy. After talking with some, people, its implementation was done even before D having templates, so, it should not be too hard to do it better than how it is now[1]. Right no no one wanted to rework on it, but everyone which tried doing a custom druntime basically dropped support for associative arrays given how confusing is to implement them. I'm working on them for Adam's minimal runtime and I just saw that implementing them would basically be as complex as implementing everything that has been done so far for this minimal wasm runtime. There is some proposals such as mapping Associative Array to a library type rather than doing bunch of hooks, which seems to be a better solution for the long run. [1]: Steve has done a new associative array implementation that maps to the current one, it has roughly 1/3 LoC the current one has and it is a lot easier to understand: https://github.com/schveiguy/newaa/blob/master/source/schlib/newaa.d --
Re: forgetting -betterC means no runtime bounds checking?
On Thursday, 5 January 2023 at 09:10:00 UTC, areYouSureAboutThat wrote: My question is: why is there no bounds checking occurring if I forget to use -betterC? module test; extern(C) void main() Note that whether bounds checking is performed depends on [compiler switches](https://dlang.org/dmd-windows.html#switch-boundscheck), and that there is a mode where `@safe` functions are checked, but `@system` functions (which your `main` appears to be) are not. This mode is the default for `-release` builds: ``` -boundscheck=[on|safeonly|off ] Controls if bounds checking is enabled. on: Bounds checks are enabled for all code. This is the default. safeonly: Bounds checks are enabled only in @safe code. This is the default for -release builds. off: Bounds checks are disabled completely (even in @safe code). This option should be used with caution and as a last resort to improve performance. Confirm turning off @safe bounds checks is worthwhile by benchmarking. ``` So, if you want bounds checking, make sure you either have `-boundscheck=on`, or use an `@safe` function together with `-boundscheck=safeonly`.
Re: forgetting -betterC means no runtime bounds checking?
On Thursday, 5 January 2023 at 09:10:00 UTC, areYouSureAboutThat
wrote:
I was playing around with betterC, when I discovered, that if i
accidently forget to provide -betterC to the compiler, it will
still compile this, but, there will be no runtime bounds
checking occuring.
My question is: why is there no bounds checking occurring if I
forget to use -betterC?
module test;
extern(C) void main()
{
import core.stdc.stdio : printf;
int[5] arr = [ 0, 1, 2, 3, 4];
for (int i = 0; i < 10; i++) // oops!
{
printf("%d\n", arr[i]);
}
}
Works on run.dlang.io for me:
```sh
0
1
2
3
4
dmd_runJFfSJW: onlineapp.d:12: Assertion 'array index out of
bounds' failed.
Error: program killed by signal 6
```
On my personal ldc 1.27.1:
```sh
(base) [tejasgarhewal@fedora ~]$ ldc2 -betterC -run ./D/oob.d
0
1
2
3
4
oob-06265c: ./D/oob.d:9: Assertion 'array overflow' failed.
Error: /tmp/oob-06265c failed with status: -2
message: Aborted (core dumped)
Error: program received signal 2 (Interrupt)
(base) [tejasgarhewal@fedora ~]$
```
Re: forgetting -betterC means no runtime bounds checking?
On Thursday, 5 January 2023 at 09:17:28 UTC, areYouSureAboutThat wrote: core.exception.ArrayIndexError@test.d(25): index [5] exceeds array of length 5 Aborted (core dumped) This is bounds checking happening.
Re: forgetting -betterC means no runtime bounds checking?
On 05/01/2023 10:17 PM, areYouSureAboutThat wrote: src/rt/dwarfeh.d:330: uncaught exception reached top of stack This might happen if you're missing a top level catch in your fiber or signal handler core.exception.ArrayIndexError@test.d(25): index [5] exceeds array of length 5 Aborted (core dumped) Looks like an exception to me, which is what the default for bounds check on error will do. Because you are not using the druntime entry point, its not being caught and made to look nice to you.
Re: forgetting -betterC means no runtime bounds checking?
On Thursday, 5 January 2023 at 09:10:00 UTC, areYouSureAboutThat wrote: btw. the output (when you forget to use -betterC): 0 1 2 3 4 src/rt/dwarfeh.d:330: uncaught exception reached top of stack This might happen if you're missing a top level catch in your fiber or signal handler core.exception.ArrayIndexError@test.d(25): index [5] exceeds array of length 5 Aborted (core dumped)
forgetting -betterC means no runtime bounds checking?
I was playing around with betterC, when I discovered, that if i
accidently forget to provide -betterC to the compiler, it will
still compile this, but, there will be no runtime bounds checking
occuring.
My question is: why is there no bounds checking occurring if I
forget to use -betterC?
module test;
extern(C) void main()
{
import core.stdc.stdio : printf;
int[5] arr = [ 0, 1, 2, 3, 4];
for (int i = 0; i < 10; i++) // oops!
{
printf("%d\n", arr[i]);
}
}
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520
Iain Buclaw changed:
What|Removed |Added
CC||ibuc...@gdcproject.org
--- Comment #6 from Iain Buclaw ---
(In reply to Walter Bright from comment #5)
> Razvan is right. This should not compile. An enum's value should evaluate to
> a constant, not a pointer to the heap.
>
> Just like this does not compile:
>
> class C { }
> C x = new C();
It's an rodata constant, you support it in the same way that
static C x = new C();
is supported.
--
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #5 from Walter Bright ---
Razvan is right. This should not compile. An enum's value should evaluate to a
constant, not a pointer to the heap.
Just like this does not compile:
class C { }
C x = new C();
--
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @WalterBright created dlang/dmd pull request #14777 "fix Issue 20520 - Runtime segfault when taking typeid of a class inst…" fixing this issue: - fix Issue 20520 - Runtime segfault when taking typeid of a class instanciated within an enum https://github.com/dlang/dmd/pull/14777 --
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 Iain Buclaw changed: What|Removed |Added Keywords||wrong-code CC|ibuc...@gdcproject.org | --
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 Iain Buclaw changed: What|Removed |Added Keywords||backend CC|ibuc...@gdcproject.org | --
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --
[Issue 20520] Runtime segfault when taking typeid of a class instanciated within an enum
https://issues.dlang.org/show_bug.cgi?id=20520 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #3 from Iain Buclaw --- GDC and LDC compile and run the test case just fine. It looks like DMD is not generating an initializer for the manifest constant referenced by `typeid()`. Tagging as backend issue. --
[Issue 20230] dmd-specific runtime segfault due to inconsistent conversion of function closure to delegate at compile time
https://issues.dlang.org/show_bug.cgi?id=20230 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 Severity|normal |critical --
[Issue 21756] Immutable array literals cause runtime GC allocation instead of static readonly section allocation
https://issues.dlang.org/show_bug.cgi?id=21756 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 --
[Issue 12190] runtime loaded shared library on osx: partially worked in 2.062, fails since 2.063
https://issues.dlang.org/show_bug.cgi?id=12190 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 10719] Loading classes in runtime
https://issues.dlang.org/show_bug.cgi?id=10719 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 10988] Add documentation on how to load DLLs at runtime
https://issues.dlang.org/show_bug.cgi?id=10988 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 10698] opDispatch called as property over struct field even when opDispatch requires runtime arguments
https://issues.dlang.org/show_bug.cgi?id=10698 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 5478] API/ABI differences/issues in d-runtime
https://issues.dlang.org/show_bug.cgi?id=5478 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 9697] removing imports or static constructors from di files can break runtime initialization order
https://issues.dlang.org/show_bug.cgi?id=9697 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 10316] DMD does not link against debug c runtime with -debug on x64 windows
https://issues.dlang.org/show_bug.cgi?id=10316 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 2270] cast produces invalid arrays at runtime
https://issues.dlang.org/show_bug.cgi?id=2270 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 4719] Clean up associative array runtime interface to enable precise GC
https://issues.dlang.org/show_bug.cgi?id=4719 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 10983] WinRT version specifier needed for the Windows Runtime
https://issues.dlang.org/show_bug.cgi?id=10983 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 16494] cannot find source code for runtime library after brew install in custom directory
https://issues.dlang.org/show_bug.cgi?id=16494 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 16414] final opCmp in interface: throws at runtime. (OK if abstract class instead of interface)
https://issues.dlang.org/show_bug.cgi?id=16414 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 20230] dmd-specific runtime segfault due to inconsistent conversion of function closure to delegate at compile time
https://issues.dlang.org/show_bug.cgi?id=20230 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 21067] Tupleof of struct returned by function with string field lazily passed to function, itself lazily passed to another function, causes runtime OOM.
https://issues.dlang.org/show_bug.cgi?id=21067 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 23032] Static variable of nested type causes runtime crash
https://issues.dlang.org/show_bug.cgi?id=23032 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 20458] CRTP + pass alias to virtual member to mixin = runtime crash
https://issues.dlang.org/show_bug.cgi?id=20458 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 15820] inconsistent error msg on assert between runtime and CT
https://issues.dlang.org/show_bug.cgi?id=15820 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
