A and B.
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B b)
pure nothrow @nogc @safe => a])` does not match template
declaration `opBi(A, A function(A, A)[string] f0)`
```
Is this a bug or am I doing something wrong?
On Friday, 1 July 2022 at 13:44:20 UTC, Chris Katko wrote:
It appears module access to a class is broken until the
constructor finishes.
No, it has nothing to do with the module. It's the reference
itself.
Until the constructor returns, the reference through which you're
constructing the
On Friday, 1 July 2022 at 13:28:26 UTC, Chris Katko wrote:
...wait, does "world" not 'exist' until after the constructor
finishes? Is that's what's going on? But then why does it
'exist' when I send it directly? Is it only "registered" with
the module once this() finishes or something like
On Friday, 1 July 2022 at 13:12:05 UTC, Adam D Ruppe wrote:
On Friday, 1 July 2022 at 12:57:01 UTC, Chris Katko wrote:
Cannot access memory at address 0x10
Looks like an ordinary null pointer. How did you create the
variable?
D
bool initialize() //called from main
{
On Friday, 1 July 2022 at 13:20:15 UTC, Mike Parker wrote:
r.
And that also looks like the source of your original segfault.
You've got a circular reference going on in the constructors.
In other words, you're constructing a global world instance,
which in turn constructs an elf instance,
On Friday, 1 July 2022 at 13:01:30 UTC, Chris Katko wrote:
Forgot the last line. That's important because world MUST exist
by time elf is called... because world... created and called
elf.
So it's not a memory issue, but some sort of linkage issue.
world is null because the constructor
On Friday, 1 July 2022 at 12:57:01 UTC, Chris Katko wrote:
Cannot access memory at address 0x10
Looks like an ordinary null pointer. How did you create the
variable?
Forgot the last line. That's important because world MUST exist
by time elf is called... because world... created and called elf.
So it's not a memory issue, but some sort of linkage issue.
To add, I cannot even access g.world from inside elf's
constructor.
... which is the function that called it.
D
Thread 1 "main" received signal SIGSEGV, Segmentation fault.
objects.elf.this(g.pair, objects.atlasHandler) (this=, atlas=,
_pos=...) at ./src/objects.d:320
(gdb) bt
#0
dmd (but I think LDC also is affected)
this bug has bit me multiple times now, to the point I can
recognize it. Accessing module variables, from inside a method,
causes a segfault. Even if the variable should be available by
then through the call order. Proving that its a bug, you can
On Wednesday, 15 June 2022 at 16:53:13 UTC, mw wrote:
Create a simple test case, file bug at:
https://issues.dlang.org/
I tried. No luck.
Create a simple test case, file bug at:
https://issues.dlang.org/
On Wednesday, 15 June 2022 at 09:24:35 UTC, Dukc wrote:
Now when I think of it, perhaps the fact that private
`printHelp` has the same name as the public `printHelp` is
somehow confusing dmd. If you try to rename the private
`printHelp` and it's call in the public one to something else,
you
On Wednesday, 15 June 2022 at 09:21:28 UTC, user1234 wrote:
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-
[Line (2)
On Wednesday, 15 June 2022 at 07:38:36 UTC, JG wrote:
I tried to reproduce it but wasn't able (I guess it is some
interplay with the rest of your code):
I tried this first but got the same result as you. I think my
small library overheats DMD's template engine.
On Tuesday, 14 June 2022 at 23:56:58 UTC, Andrey Zherikov wrote:
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-
[Line (2)
produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=true#step:5:12) `undefined reference to
On Tuesday, 14 June 2022 at 23:56:58 UTC, Andrey Zherikov wrote:
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both
On Tuesday, 14 June 2022 at 19:49:39 UTC, Steven Schveighoffer
wrote:
On 6/14/22 3:35 PM, JG wrote:
Hi,
Is this a bug?
```d
import std;
template test(alias f) {
auto test(I)(I i) { return f(i); }
}
void main()
{
alias t = test!(x=>x+1);
1.t.writeln; //<--Doesn't c
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both of the
templates.
This definitely triggers some bug in DMD because
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/help.d#L27-L47):
```d
alias CC = SumType!(AA,BB);
struct AA {}
struct BB
{
CC[] c;
}
private void ppp(T, Output
On 6/14/22 3:35 PM, JG wrote:
Hi,
Is this a bug?
```d
import std;
template test(alias f) {
auto test(I)(I i) { return f(i); }
}
void main()
{
alias t = test!(x=>x+1);
1.t.writeln; //<--Doesn't compile
1.test!(x=>x+1).writeln;
t(1).writeln;
}
```
Not a b
Hi,
Is this a bug?
```d
import std;
template test(alias f) {
auto test(I)(I i) { return f(i); }
}
void main()
{
alias t = test!(x=>x+1);
1.t.writeln; //<--Doesn't compile
1.test!(x=>x+1).writeln;
t(1).writeln;
}
```
I have [pretty simple code in my
library](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/help.d#L27-L47):
```d
alias CC = SumType!(AA,BB);
struct AA {}
struct BB
{
CC[] c;
}
private void ppp(T, Output)(auto ref Output output, in
CommandArguments!T cmd, in Config
Hi,
I was reading the source of std.algorithm cache and saw some code
that didn't make sense to me with a comment indexing the [bug
report](https://issues.dlang.org/show_bug.cgi?id=15891). Could
anyone help to understand if this code is really necessary
(meaning I have some misconception
On Saturday, 18 December 2021 at 12:50:17 UTC, Tejas wrote:
As Ali said, this is an implementation issue.
So I guess the answer to your question is that this is a bug.
Please file a report at [issues.dlang.org](issues.dlang.org)
Looks like this is same case:
https://issues.dlang.org
guess the answer to your question is that this is a bug.
Please file a report at [issues.dlang.org](issues.dlang.org)
On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote:
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
```
Interesting what discussed behaviour isn't affects method what
implements same functionality as dtor and called explictly at
each
On Friday, 17 December 2021 at 18:51:56 UTC, Ali Çehreli wrote:
On 12/17/21 10:01 AM, Tejas wrote:
> [...]
Storage,
There is no such requirement nor guarantee.
[...]
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
void main()
{
immutable S
On 12/17/21 10:01 AM, Tejas wrote:
> I think since `immutable` objects are kept in Read Only Storage,
There is no such requirement nor guarantee.
> you
> can't call destructors on them
Destructor is nothing but a piece of code that is executed when an
object's life ends. A destructor need
On Friday, 17 December 2021 at 18:32:43 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 18:02:52 UTC, Tejas wrote:
I improved your sample:
```d
immutable struct S
{
~this() {}
}
immutable struct S2
{
S sss;
~this() {}
}
void main()
{
S2 s = S2();
}
```
```
Error:
On Friday, 17 December 2021 at 18:02:52 UTC, Tejas wrote:
I improved your sample:
```d
immutable struct S
{
~this() {}
}
immutable struct S2
{
S sss;
~this() {}
}
void main()
{
S2 s = S2();
}
```
```
Error: `immutable` method `serializer_bug.S.~this` is not
callable using a
On Friday, 17 December 2021 at 18:19:34 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
I think since `immutable` objects are kept in Read Only Storage
Some of them can be stored in ROM in some cases, but actually
"immutable" keyword means "not mutable
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
I think since `immutable` objects are kept in Read Only Storage
Some of them can be stored in ROM in some cases, but actually
"immutable" keyword means "not mutable for whole its lifetime"
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
On Friday, 17 December 2021 at 17:34:05 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
[...]
("serializer_bug" is just name of my local .d file)
I think since `immutable`
On Friday, 17 December 2021 at 17:34:05 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
~this() {} // Comment out this to fix this compilation
error:
// Error: `immutable` method `serializer_bug.Imm.~this` is
("serializer_bug" is
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
~this() {} // Comment out this to fix this compilation
error:
// Error: `immutable` method `serializer_bug.Imm.~this` is
("serializer_bug" is just name of my local .d file)
```d
/+ dub.json:
{
"name": "test",
"dependencies": {
}
}
+/
struct S
{
~this() {}
}
immutable class Imm
{
S s; // this is immutable value because whole class is
immutable
this()
{
s = S();
}
~this() {} // Comment out this to fix this compilation
On Monday, 13 December 2021 at 18:24:07 UTC, Andre Pany wrote:
On Sunday, 12 December 2021 at 05:54:44 UTC, Chris Katko wrote:
Running 64-bit Linux
```
dmd --version
DMD64 D Compiler v2.098.0-beta.2
[...]
I really recommend always using dub configurations, especially
when you want to use
On 12/12/21 12:54 AM, Chris Katko wrote:
Running 64-bit Linux
```
dmd --version
DMD64 D Compiler v2.098.0-beta.2
dub --version
DUB version 1.27.0-beta.2, built on Sep 7 2021
```
the following code 'compiles' in one project.
```d
unittest
{
gasdindgaslkdgansklnasgdlknaglkgansklsdg;
}
void
On Sunday, 12 December 2021 at 05:54:44 UTC, Chris Katko wrote:
Running 64-bit Linux
```
dmd --version
DMD64 D Compiler v2.098.0-beta.2
[...]
I really recommend always using dub configurations, especially
when you want to use unit tests.
The name of the first configuration doesn't matter.
You are running the beta version of the compiler, and an older
version of LDC2
I'd first try to update them to make sure you aren't missing any
bug fixes
ot;,
"name": "widescreen"
}
```
dub.json.selections (for broken project only)
```json
{
"fileVersion": 1,
"versions": {
"crypto": "0.2.16",
"intel-intrinsics": "1.6.1"
}
}
```
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote:
With nothing to the contrary, I'd take "must be terminated by a
null pointer" as "can't itself be a null pointer".
The execve(2) is more explicit:
"The argument argv is a pointer to a null-terminated array of
character pointers
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote:
[...]
With nothing to the contrary, I'd take "must be terminated by a
null pointer" as "can't itself be a null pointer".
ah yeah, and thanks, of course ... how would the count of arg be
known without the sentinel...
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
What do you think ?
I'm very surprised that this is even allowed. Apparently it's
Linux userspace that normally complains about it:
https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/progname.c#n54
The manpages just say
```
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
The following code, on linux
[...]
What do you think ?
Forgot to say that this change
```diff
- execv("a", null);
+ execv("a", ["whatever".ptr].ptr);
```
makes the problem goes away, so it would be caused by how `null`
args are
The following code, on linux
```d
module runnable;
extern(C) int execv(const char* p, const char** args);
immutable src = `
import std.getopt;
void main(string[] args)
{
bool c;
getopt(args, "c", );
}
`;
void prepareProgram()
{
import std.process :
On Fri, Oct 01, 2021 at 06:30:48PM +, Danny Arends via Digitalmars-d-learn
wrote:
[...]
> Is there a sort() algorithm that avoids swapping the items themselves
> and e.g. just returns the indexes so I can reorder the original array
> myself ?
On Friday, 1 October 2021 at 17:53:24 UTC, Steven Schveighoffer
wrote:
I think your struct is different than this, because this only
happens if aliasing is inside the struct being sorted (i.e. it
has pointers). Your presented struct doesn't have pointers, and
the code you linked to is
On 10/1/21 12:44 PM, Danny Arends wrote:
Hey all,
Using a modified 3D A* tile searching algorithm, full code see:
https://github.com/DannyArends/CalderaD/blob/master/src/math/search.d
I get the following AssertError, 'sometimes' but not always on running
the code:
mutation.d(2816): Swap:
Hey all,
Using a modified 3D A* tile searching algorithm, full code see:
https://github.com/DannyArends/CalderaD/blob/master/src/math/search.d
I get the following AssertError, 'sometimes' but not always on
running the code:
mutation.d(2816): Swap: rhs points to lhs.
the first time I hit
On Friday, 17 September 2021 at 10:29:12 UTC, bauss wrote:
On Friday, 17 September 2021 at 09:44:53 UTC, Chris Katko wrote:
[...]
It's not a bug because "obj.x" referes to the same symbol that
is "this.x"
Alias will create an alias for a symbol, not an expression or
t
}
/*
output:
x1: 50 y1: 81 w1: 5 h1: 6
x2: 50 y2: 81 w2: 5 h2: 6 <
x1: 50 y1: 81 w1: 5 h1: 6
x2: 200 y2: 86.54 w2: 26 h2: 16 <
*/
```
The arrows point to the dependency. The top two sets of numbers
should _not_ be identical.
It's not a bug bec
if
it's considered a bug.
I'm debugging some code I wrote back in 2017 and a bounding box
collision detection kept giving spurious answers till I resorted
to assuming nothing and dumped every variable and alias.
I kept getting results like it was checking against itself, and
of course, that would result in finding a
On Saturday, 14 August 2021 at 08:23:20 UTC, user1234 wrote:
On Saturday, 14 August 2021 at 04:09:34 UTC, Tejas wrote:
[...]
Oh right, the ```.``` operator will reference variable in the
_module_ scope, not just the _immediate outer scope_,
you can use the module name to disambiguate as
On Saturday, 14 August 2021 at 04:09:34 UTC, Tejas wrote:
[...]
Oh right, the ```.``` operator will reference variable in the
_module_ scope, not just the _immediate outer scope_,
you can use the module name to disambiguate as well. To extend
Mike answer, the general rule is that if you can
On Saturday, 14 August 2021 at 04:01:31 UTC, Mike Parker wrote:
On Saturday, 14 August 2021 at 03:47:05 UTC, Tejas wrote:
```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}
auto def(T)(auto ref T a, auto ref T b){
return a*b;
}
alias macro_1 = abc;
void main()
On Saturday, 14 August 2021 at 03:47:05 UTC, Tejas wrote:
```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}
auto def(T)(auto ref T a, auto ref T b){
return a*b;
}
alias macro_1 = abc;
void main()
{
writeln(macro_1(15, 20));
alias macro_1 = def;// is
```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}
auto def(T)(auto ref T a, auto ref T b){
return a*b;
}
alias macro_1 = abc;
void main()
{
writeln(macro_1(15, 20));
alias macro_1 = def;// is this NOT considered variable
shadowing?
On Monday, 28 June 2021 at 20:55:44 UTC, solidstate1991 wrote:
Here's the offending function:
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/sortedlist.d#L38
It causes to throw an exception with `Access violation reading
location` and a memory address, int the
On Monday, 28 June 2021 at 21:45:05 UTC, frame wrote:
The SpriteLayer.addSprite() method accepts ushort. That's max.
65535. You supply 65_536.
Ah I mixed the argumets, forget that.
However, your comment
//ocd.objects[65_536]
may also I hint that you try to access elements that are not
On Monday, 28 June 2021 at 20:55:44 UTC, solidstate1991 wrote:
Here's the offending function:
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/sortedlist.d#L38
It causes to throw an exception with `Access violation reading
location` and a memory address, int the
Here's the offending function:
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/sortedlist.d#L38
It causes to throw an exception with `Access violation reading
location` and a memory address, int the function
`_d_arraysetlengthT`. Variable `ti` is a TypeInfo_Array,
On Sunday, 27 June 2021 at 20:12:09 UTC, jfondren wrote:
On Sunday, 27 June 2021 at 19:50:09 UTC, Matilda wrote:
[...]
This works with either readf line for me on v2.097.0.
Try stracing your program.
Okay, thank you. I'll try it out.
There is no error message. It just waits for nothing
apparently. It works with the stip.to!int line, so the problem
must be with readf.
I'm kind of new to this language and I don't have much
experience with programming in general, so I have no way to
know if it's just me being dumb or I've accident
. It works with the stip.to!int line, so the problem
must be with readf.
I'm kind of new to this language and I don't have much experience
with programming in general, so I have no way to know if it's
just me being dumb or I've accidently found a bug.
I use DMD32 D Compiler v2.097.0-dirty
On Wednesday, 7 April 2021 at 17:31:09 UTC, Paul Backus wrote:
On Wednesday, 7 April 2021 at 17:04:56 UTC, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
On Wednesday, 7 April 2021 at 17:31:09 UTC, Paul Backus wrote:
It's not your fault--this is a pretty obscure feature, and it's
not documented very well. Even after you've found the correct
page in the documentation (the page for `formattedWrite` [1]),
you have to scroll down past multiple
On 4/7/21 10:04 AM, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
For the sake of completeness, I mention this feature in a couple of
other places:
On Wednesday, 7 April 2021 at 17:04:56 UTC, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
It's not your fault--this is a pretty obscure feature, and
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
On Wednesday, 7 April 2021 at 13:31:59 UTC, novice3 wrote:
there is extra quotes, wich not present in firmat specifier.
is this bug, or i should change something in my code?
This is actually an intentional feature (albeit kind of a stupid
one). From the documentation:
Inside a compound
https://run.dlang.io/is/p4NVp8
```d
void main()
{
import std.stdio: writefln;
string[] s = ["a", "b", "c"];
writefln("%(%s, %)", s);
}
```
output
```d
"a", "b", "c"
```
expected
```d
a, b, c
```
there is extra
On Thursday, 11 March 2021 at 17:41:27 UTC, rikki cattermole
wrote:
Try it with:
-allinst
It may just be deciding a template instance isn't required.
The error message could maybe be changed to include this? "Try
-allinst bla bla"
On Thursday, 11 March 2021 at 17:41:27 UTC, rikki cattermole
wrote:
Try it with:
-allinst
It may just be deciding a template instance isn't required.
Good workaround for such kind of bugs! )
Up to 2.063 : Failure with output: Error: unrecognized
switch '-allinst'
Since 2.064 :
Try it with:
-allinst
It may just be deciding a template instance isn't required.
On 3/11/21 8:41 AM, Iliya wrote:
> I am using dmd 2.094.1 on linux
Your program links fine for me with 2.094.2 on Linux.
Ali
On Thursday, 11 March 2021 at 17:25:35 UTC, Ali Çehreli wrote:
On 3/11/21 8:41 AM, Iliya wrote:
> I am using dmd 2.094.1 on linux
Your program links fine for me with 2.094.2 on Linux.
Ali
Thank you, Ali!
I also played with it on playground. Seems that it is a bug.
The compilation resu
on:
1. Why compiler searches for such function attributes - pure
nothrow @nogc @safe, as I don't specify them. Is this a bug or
feature?)
2. What changes are needed to compile this rather simple example.
Please, help me!
Reference to my piece of code in app.d:
struct IsEqual(T)
{
static
On 9/29/20 4:38 PM, drug wrote:
It reproduces. As a workaround you can use
```
dub run profdump
```
this command works as expected, I guess it is a bug of dub
Do not execute this command in cloned `profdump` repository - it will
fail too. It works if is called from other places, for example
On 9/29/20 3:41 PM, mw wrote:
I remember I used to able to build this package:
https://github.com/AntonMeep/profdump
but now, I cannot.
Since that package haven't changed for 2 years, maybe it's a dub bug?
System information
$ uname -a
Linux 4.15.0-117-generic #118-Ubuntu SMP Fri Sep 4 20
I remember I used to able to build this package:
https://github.com/AntonMeep/profdump
but now, I cannot.
Since that package haven't changed for 2 years, maybe it's a dub
bug?
System information
$ uname -a
Linux 4.15.0-117-generic #118-Ubuntu SMP Fri Sep 4 20:02:41 UTC
2020 x86_64
On Wednesday, 2 September 2020 at 20:55:34 UTC, Andrey Zherikov
wrote:
I think the issue is here:
https://github.com/dlang/dmd/blob/master/src/dmd/root/filename.d#L736-L748
Yes, issue is there. This change (removal of "c == '\\' || ")
fixes it:
diff --git a/src/dmd/root/filename.d
On Wednesday, 2 September 2020 at 19:13:47 UTC, Adam D. Ruppe
wrote:
On Wednesday, 2 September 2020 at 18:40:55 UTC, Andrey Zherikov
wrote:
If I provide -Jfoo to dmd, doesn't it mean my consent to use
the contents of directory foo?
Yeah, but dmd has been inconsistent on platforms about if it
foo\bar" paths on Windows.
I don't know why it wouldn't work with native paths on Windows. But I'm
not a DMD maintainer, so I don't know where to look in the code to see
why it doesn't work.
It might be worth filing a bug. https://issues.dlang.org
-Steve
On Wednesday, 2 September 2020 at 20:23:15 UTC, Steven
Schveighoffer wrote:
What I'm wondering is if it needs to be ./file instead of
.\file. Can you hard code that and see if it works?
This actually works:
pragma(msg, import("file"));
pragma(msg, buildPath(".", "file"));
On 9/2/20 1:47 PM, Adam D. Ruppe wrote:
On Wednesday, 2 September 2020 at 17:39:04 UTC, Andrey Zherikov wrote:
Is this a bug in dmd?
I think it is an old bug filed (I can't find it though) about
inconsistent platform behavior but it is allowed by spec for the
compiler to reject any path
On Wednesday, 2 September 2020 at 18:40:55 UTC, Andrey Zherikov
wrote:
If I provide -Jfoo to dmd, doesn't it mean my consent to use
the contents of directory foo?
Yeah, but dmd has been inconsistent on platforms about if it
allows subdirectories. Right now I think it just strips all
slashes
On Wednesday, 2 September 2020 at 17:47:47 UTC, Adam D. Ruppe
wrote:
On Wednesday, 2 September 2020 at 17:39:04 UTC, Andrey Zherikov
wrote:
Is this a bug in dmd?
I think it is an old bug filed (I can't find it though) about
inconsistent platform behavior but it is allowed by spec
On Wednesday, 2 September 2020 at 17:39:04 UTC, Andrey Zherikov
wrote:
Is this a bug in dmd?
I think it is an old bug filed (I can't find it though) about
inconsistent platform behavior but it is allowed by spec for the
compiler to reject any path components.
import("") is suppos
Adding some verbosity:
pragma(msg, import("file"));
pragma(msg, buildPath(".", "file"));
pragma(msg, import(buildPath(".", "file")));
Result on Ubuntu:
===
hello
./file
hello
===
Result on Windows:
===
hello
.\file
parser.d(47): Error: file ".\\file" cannot be found
run test.d
Result on Ubuntu:
===
hello
hello
===
Result on Windows:
===
hello
test.d(46): Error: file ".\\file" cannot be found or not in a
path specified with -J
test.d(46):while evaluating pragma(msg,
import(buildPath([".", "file"][])))
===
Is this a bug in dmd?
are allocated on the caller's stack instead; so adding `scope` for
these variadics *should* probably do the same:
void tester(Test test, scope Test[] tests...);
Note that without the initial parameter, or without the destructor, they
do NOT end up on the heap.
I think this is a bug
; so adding `scope` for these
variadics *should* probably do the same:
void tester(Test test, scope Test[] tests...);
Note that without the initial parameter, or without the destructor, they
do NOT end up on the heap.
I think this is a bug, and not a "feature". I can't see any
On Monday, 6 July 2020 at 22:02:37 UTC, Kayomn wrote:
On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote:
Similar case here; the 'varargs' end up in a GC-allocated
array. I've recently changed `scope` slice params, so that
array literal arguments are allocated on the caller's stack
instead;
On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote:
Similar case here; the 'varargs' end up in a GC-allocated
array. I've recently changed `scope` slice params, so that
array literal arguments are allocated on the caller's stack
instead; so adding `scope` for these variadics *should*
On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote:
Though, admittedly I'm kind of used to seeing this error
message since it appears any time you try and do something that
relies on type info in betterC, intentionally or not. A notable
example is forgetting to supply an arrange length when
On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote:
example is forgetting to supply an arrange length when
array length*
101 - 200 of 1912 matches
Mail list logo
