Re: Bug fixes for Mac OSX landing in 2.107.1
On Tuesday, 27 February 2024 at 07:48:20 UTC, Iain Buclaw wrote: Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013. Yes, all issues reported by the Xcode 15 linker were subtle corruptions of the mach-o format that are (mostly) silently accepted by the Xcode 14 and older linkers. MacOS 10.7 remains to be the absolute minimum version supported due to the requirement of native TLS. This'll only be bumped to 10.8/10.9 when coalesced sections get dropped (https://issues.dlang.org/show_bug.cgi?id=22464). Nice, thanks!
Re: Bug fixes for Mac OSX landing in 2.107.1
On Tuesday, 27 February 2024 at 06:08:51 UTC, Danilo wrote: On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x. Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013. Yes, all issues reported by the Xcode 15 linker were subtle corruptions of the mach-o format that are (mostly) silently accepted by the Xcode 14 and older linkers. MacOS 10.7 remains to be the absolute minimum version supported due to the requirement of native TLS. This'll only be bumped to 10.8/10.9 when coalesced sections get dropped (https://issues.dlang.org/show_bug.cgi?id=22464).
Re: Bug fixes for Mac OSX landing in 2.107.1
On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x. Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013.
Re: Bug fixes for Mac OSX landing in 2.107.1
On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: Hi, Over the last 2-3 years, there's been a slow build-up of issues on MacOS that have now come home to roost, and they could no longer be ignored/worked arounded in CI as GHA has made Xcode 15.0.1 the default SDK since ~end of January/February 2024. [...] This is great Ian! The unaligned pointers and macosx development issue have plagued students for a long time (the workarounds were possible but confusing). Will give it a try after March 1st
Re: Bug fixes for Mac OSX landing in 2.107.1
Wow! This is really good work. It's much appreciated!
Re: Bug fixes for Mac OSX landing in 2.107.1
On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: Hi, Over the last 2-3 years, there's been a slow build-up of issues on MacOS that have now come home to roost, and they could no longer be ignored/worked arounded in CI as GHA has made Xcode 15.0.1 the default SDK since ~end of January/February 2024. [...] Wow. Good job.
Bug fixes for Mac OSX landing in 2.107.1
Hi, Over the last 2-3 years, there's been a slow build-up of issues on MacOS that have now come home to roost, and they could no longer be ignored/worked arounded in CI as GHA has made Xcode 15.0.1 the default SDK since ~end of January/February 2024. **RESOLVED**: Linker errors - [ld: symbol count from symbol table and dynamic symbol table differ](https://github.com/dlang/dmd/pull/16221) This was caused by off-by-one mismatch in codegen symbol counters for the two tables. - [ld: unaligned pointer(s) for architecture x86_64](https://github.com/dlang/dmd/pull/16224) / warning: alignment (1) of atom 'anon' is too small and may result in unaligned pointers / warning: pointer not aligned at address This was caused by DMD forcing `__debug_line` sections to be emitted into the final executable to work around lack of backtrace support on OSX. This section now has the _correct_ flags assigned to it so it gets discarded at link-time - see notes on BREAKING changes. - [ld: GOT load reloc does not point to a movq instruction](https://github.com/dlang/dmd/pull/16227) Sometimes it was only seen with `dmd -O`, sometimes caused by `long * int` expressions. The underlying cause was symbol references being emitted as `X86_64_RELOC_GOT_LOAD` in the relocation table, but the instruction that accessed the symbol wasn't `MOVQ`. - [ld: address=0x0 points to section(2) with no content](https://github.com/dlang/dmd/pull/16222) This was triggered by g/shared array instantiated from a template and initialized with `[]` - such as the the variable `string[] rt_options = []` in D runtime - its empty initializer was being written to a data section that expected non-empty data. **RESOLVED**: Linker warnings - [ld: warning: pointer not aligned at __OBJC_PROTOCOL_$](https://github.com/dlang/dmd/pull/16219) This was caused by `extern(Objective-C)` functions and/or variables being emitted as `align(3)`. - [ld: warning: no platform load command found, assuming: macOS](https://github.com/dlang/dmd/pull/16223) This was caused by a missing `LC_BUILD_VERSION` command in all compiled modules. Jacob Carlborg did [the hard work years ago](https://github.com/dlang/dmd/pull/10476) to add support. Instead though a simplified version was committed that didn't include support for embedding CoreFoundation/framework/SDK version information in compiled objects - it wasn't necessary to fix the issue, and the linker fills in all SDK information for us anyway. **WONTFIX**: Workarounds - [ld: Assertion failed: (slot < _sideTableBuffer.size())](https://github.com/dlang/dmd/pull/16240) / ld: Assertion failed: (resultIndex < sectData.atoms.size()) Whilst the cause is unknown, the trigger is by using DMD with Xcode 15.0.1. The assumption is that the linker supplied with Xcode 15.0.1 is unstable/buggy as code generated by GCC/G++/G... also triggered this assertion. The confirmed fix is to upgrade to at least **Xcode 15.1** / CommandLineTools for Xcode 15.1. **CHANGES**: - **BREAKING**: File/line information is no longer embedded into the executable via `__debug_line` section. On developer machines, backtraces will still work as expected as D runtime supports getting this information instead via the `atos` command. Someone with a vested interest should look into adding `.dSYM` support to D runtime. (https://issues.dlang.org/show_bug.cgi?id=20510) - Setting `MACOSX_DEPLOYMENT_TARGET` now results in its value being embedded into all compiled objects for macOS. An invalid setting will result in a compile-time error. - As a result of all the above issues, it is impossible to build anything with DMD when using Xcode 15. The interim workaround to build DMD itself is to use LDC as the host compiler. This will be resolved as soon as 2.107.1 is released. This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x. If there's interest in making an RC release ahead of 1st March so MacOS/x86 users can do any last minute checking, now would be the time to know. There's been no testing on any real world project. Iain.
Re: Weird bug in std.logger? Possible memory corruption
On 1/11/23 18:26, Christian Köstlin wrote: It's really weird: https://run.dlang.io/is/fIBR2n I think I might have found out the issue. It's indeed related to the lazy parameter and reentrance. The usual logger functions consist of three parts: a header, the message, and the "finalizer". [1]. Internally this is implemented using a string appender [2, 3]. However, this string appender is a member of the class, and this is the source of the bug, because it's shared among all the calls to the logger. It's usually protected by a mutex, so different threads don't mess with each other, but it didn't take reentrancy into account. And so the call to the logging function within `foo` takes place once the appender is already populated, so this is what happens: 1. Header of first call to `log` (`info`, in this case, but it's irrelevant). 2. Body of first invocation -> Call to `foo()` -> Second call to `log`. 3. The buffer is cleared: The first header is discarded (and previous body, if there were any). 4. The second invocation proceeds normally, and the control returns to the first invocation 5. Now the buffer contains the full content of the previous call, and the return of `foo` is added. This is exactly what we see. If we do an assignment **before**, then the call is no longer reentrant and everything happens as expected. So I'd still call it a bug, but at least there seems to be no memory corruption. Also, it doesn't have an easy way to fix it without changing the interface (and potentially affecting already existing custom implementations). In my view, `writeLogMsg` should create a brand new appender (not a member of the class) that would be passed as a parameter to `beginLogMsg`, `logMsgPart` and `finishLogMsg()`. Anyway, I think the mystery is more or less solved. [1]: https://dlang.org/phobos/std_logger_core.html#.Logger [2]: https://github.com/dlang/phobos/blob/master/std/logger/core.d#L1401 [3]: https://github.com/dlang/phobos/blob/master/std/logger/core.d#L619-L641
Re: Weird bug in std.logger? Possible memory corruption
On Wednesday, 1 November 2023 at 17:26:42 UTC, Christian Köstlin wrote: ... It's really weird: https://run.dlang.io/is/fIBR2n Interesting because I wrote a similar test as you did. And that increment (Or lack of) called my attention, If I can I'll try and take a look at that (std.logger) info() Implementation later after work. Matheus.
Re: Weird bug in std.logger? Possible memory corruption
On Wednesday, 1 November 2023 at 14:15:55 UTC, matheus wrote:
On Tuesday, 31 October 2023 at 21:19:34 UTC, Arafel wrote:
...
Assigning the value to a variable works as expected:
```d
import std.logger : info;
void main() {
auto s = foo();
info(s);
}
auto foo() {
info("In foo");
return "Hello, world.";
}
```
...
Unless you do:
string s;
info(s=foo());
I think this is a bug, or at least very weird behavior.
Matheus.
It's really weird: https://run.dlang.io/is/fIBR2n
Re: Weird bug in std.logger? Possible memory corruption
On Tuesday, 31 October 2023 at 21:19:34 UTC, Arafel wrote:
...
Assigning the value to a variable works as expected:
```d
import std.logger : info;
void main() {
auto s = foo();
info(s);
}
auto foo() {
info("In foo");
return "Hello, world.";
}
```
...
Unless you do:
string s;
info(s=foo());
I think this is a bug, or at least very weird behavior.
Matheus.
Re: Weird bug in std.logger? Possible memory corruption
I can only imagine that it's related to the logging functions taking lazy arguments, although I cannot see why it would be a problem in a simple case like this. I've been thinking a bit more about it, and it must be indeed because of the lazy argument. `foo()` is an argument to `info`, but it also uses the logger. However, because it's a lazy argument, it's not called from `main`, but from `info` itself. I strongly suspect that the problem is that it's not reentrant. I'm not clear what it's supposed to happen, but assuming this case won't be supported, it should at least be documented. Should I open a bug about it?
Weird bug in std.logger? Possible memory corruption
Hi,
Today I have just found a weird bug in std.logger. Consider:
```d
import std.logger : info;
void main() {
info(foo());
}
auto foo() {
info("In foo");
return "Hello, world.";
}
```
The output is:
```
2023-10-31T20:41:05.274 [info] onlineapp.d:8:foo In foo
2023-10-31T20:41:05.274 [info] onlineapp.d:8:foo In fooHello, world.
```
The second line is obviously wrong, as it repeats the first line as its
header. That's why I suspect memory corruption.
Assigning the value to a variable works as expected:
```d
import std.logger : info;
void main() {
auto s = foo();
info(s);
}
auto foo() {
info("In foo");
return "Hello, world.";
}
```
gets the proper output:
```
2023-10-31T21:09:46.529 [info] onlineapp.d:9:foo In foo
2023-10-31T21:09:46.529 [info] onlineapp.d:5:main Hello, world.
```
I can only imagine that it's related to the logging functions taking
lazy arguments, although I cannot see why it would be a problem in a
simple case like this.
[Issue 21588] Please add a way to setup a "Dustmite" when project build is failed because of DMD or Link failed because of DMD bug
https://issues.dlang.org/show_bug.cgi?id=21588 --- Comment #6 from dlangBugzillaToGithub --- THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/visuald/issues/239 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB --
[Issue 24163] New: Floating-point variadic array bug
https://issues.dlang.org/show_bug.cgi?id=24163
Issue ID: 24163
Summary: Floating-point variadic array bug
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: evilrat...@gmail.com
Here is a "funny" bug with variadic function taking float arguments, whenever
foo takes the float parameter and Vector2 is a larger type then the second
assert fails.
It works as expected when foo and Vector2 is both float or double, or foo is
not float.
There is a strange behavior in the foo as well.
Note that this only happens with DMD, with LDC it works correctly.
This code is tested on Windows.
Reproduction code
--
alias real_t = double;
struct Vector2 {
real_t x, y;
this(real_t x, real_t y) { this.x = x; this.y = y; }
}
Vector2 foo(size_t nArgCount)(float[nArgCount] args...)
{
//import std.stdio;
//writeln(args); // [0.5]
//writeln(args[0]); // 0
//assert(args[0] == 0.5f); // assert failed
return Vector2(args[0], args[0]);
}
void main()
{
// ok
auto c = foo(0.5, 0.5);
assert(c.x == 0.5 && c.y == 0.5);
// Note that it is just by coincidence that the stack is zeroed,
// in real program there will be garbage values.
// This bug happens ONLY when foo type is float and Vector2 any other type.
// It works properly with LDC, but not with DMD.
import std.stdio;
c = foo(0.5);
writefln("%f, %f", c.x, c.y); // 0.00, 0.00
assert(c.x == 0.5 && c.y == 0.5);
}
--
Re: Weird floating point rounding - Bug or how to control it correctly
On Thursday, 14 September 2023 at 03:23:48 UTC, An Pham wrote:
import std.stdio;
void main()
{
float f = 6394763.345f;
import std.format : sformat;
char[80] vBuffer = void;
writeln("6394763.345 = ", sformat(vBuffer[], "%.4f",
f));
}
Output
6394763.345 = 6394763.5000
Classic question. The float literal `6394763.345f` is not
representable as IEEE-754 floating point number.
Try https://www.h-schmidt.net/FloatConverter/IEEE754.html for a
short introduction to the issue.
Re: Weird floating point rounding - Bug or how to control it correctly
On Wednesday, September 13, 2023 9:23:48 PM MDT An Pham via Digitalmars-d-
learn wrote:
> import std.stdio;
>
> void main()
> {
> float f = 6394763.345f;
>
> import std.format : sformat;
>
> char[80] vBuffer = void;
> writeln("6394763.345 = ", sformat(vBuffer[], "%.4f", f));
>
> }
>
> Output
> 6394763.345 = 6394763.5000
The nature of floating point numbers is such that there a bunch of values
that they can't actually represent, and they get rounded pretty easily
depending on the exact numbers involved. So, in general, you shouldn't
expect floating point numbers to be exact. You will generally do better with
increased precision though, and in this case, it looks like your number will
stay the same if you use double or real instead of float.
I would suggest that you watch this video from dconf 2016 which discusses
floating point values:
https://www.youtube.com/watch?v=YEUAUnamQiA
- Jonathan M Davis
Weird floating point rounding - Bug or how to control it correctly
import std.stdio;
void main()
{
float f = 6394763.345f;
import std.format : sformat;
char[80] vBuffer = void;
writeln("6394763.345 = ", sformat(vBuffer[], "%.4f", f));
}
Output
6394763.345 = 6394763.5000
Re: Bug in usage of associative array: dynamic array with string as a key
On 6/30/23 17:42, Cecil Ward wrote:
> https://dlang.org/spec/hash-map.html#testing_membership in the language
> docs, under associative arrays - 13.3 testing membership. Would anyone
> else care to try that example out as that might be quicker?
I tried it by
1) Putting all the code inside a 'void main()' function
2) Pasting the code from the top of that page
and it works:
void main() {
int[string] aa; // Associative array of ints that are
// indexed by string keys.
// The KeyType is string.
aa["hello"] = 3; // set value associated with key "hello" to 3
int value = aa["hello"]; // lookup value from a key
assert(value == 3);
int* p;
p = "hello" in aa;
if (p !is null)
{
*p = 4; // update value associated with key
assert(aa["hello"] == 4);
}
}
> the only substantive
> change being deleting the variable p
Do you mean this:
aa.remove("hello");
That works too.
D's associative arrays have a few quirks but they work just fine. They
are not buggy as it may be inferred from some of the posts here.
Ali
Re: Bug in usage of associative array: dynamic array with string as a key
On Friday, 30 June 2023 at 19:05:23 UTC, Cecil Ward wrote:
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
Decls.ordinals[ str ] = ordinal_counter++;
The problem is that it always returns ordinal== -1 from the
expression. Can you sort me out? I took this from the example
given in the language reference under arrays, testing for
membership (or similar, I forget the subssection title).
From good old printfs it seems to be the case that the array is
being populated (elsewhere) with the expected correct values.
Taking out the if doesn’t seem to help either. I don’t have a
way of examining the contents of the dynamic array directly to
check that they are actually being stored as expected, other
than seeing that that line of code is indeed being executed
with the expected values of str going in. Note that I’m using
32-bit dstrings everywhere, not strings of bytes.
Fool that I am. I did those good old printfs a while back, and
now I recheck them I see that something has become broken and it
seems that the insertions are not happening now. So thankyou for
your kindness and I’ll post again if that doesn’t solve the
non-issue.
Re: Bug in usage of associative array: dynamic array with string as a key
On Friday, 30 June 2023 at 21:25:23 UTC, H. S. Teoh wrote: On Fri, Jun 30, 2023 at 07:05:23PM +, Cecil Ward via Digitalmars-d-learn wrote: [...] It would help if you could post the complete code that reproduces the problem. Or, if you do not wish to reveal your code, reduce it to a minimal case that still exhibits the same problem, so that we can see it for ourselves. The snippets you provided do not provide enough information to identify the problem. T I would indeed need to cut it down massively, as the original code is ~2k lines. Mind you, I will just end up with the example at https://dlang.org/spec/hash-map.html#testing_membership in the language docs, under associative arrays - 13.3 testing membership. Would anyone else care to try that example out as that might be quicker? That’s because as all I did was copy that basically, with the only substantive change being deleting the variable p, but I’m still testing whether or not I get a null pointer. I thought I had checked that the insertions were all as expected, so I’ll go and recheck that next.
Re: Bug in usage of associative array: dynamic array with string as a key
https://forum.dlang.org/thread/duetqujuoceancqtj...@forum.dlang.org Try HashMap see if it is still a problem. If no, then it's another example of the built in AA problem.
Re: Bug in usage of associative array: dynamic array with string as a key
On Fri, Jun 30, 2023 at 07:05:23PM +, Cecil Ward via Digitalmars-d-learn wrote: [...] It would help if you could post the complete code that reproduces the problem. Or, if you do not wish to reveal your code, reduce it to a minimal case that still exhibits the same problem, so that we can see it for ourselves. The snippets you provided do not provide enough information to identify the problem. T -- What's the difference between a 4D tube and an overweight Dutchman? One is a hollow spherinder, and the other is a spherical Hollander.
Re: Bug in usage of associative array: dynamic array with string as a key
On 6/30/23 13:16, Cecil Ward wrote: On Friday, 30 June 2023 at 19:58:39 UTC, FeepingCreature wrote: Note that you can do `uint ordinal = Decls.ordinals.get(str, -1);`. Is the second argument an ‘else’ then, my friend? Yes, .get and friends appear in this table: https://dlang.org/spec/hash-map.html#properties Ali
Re: Bug in usage of associative array: dynamic array with string as a key
On Friday, 30 June 2023 at 19:58:39 UTC, FeepingCreature wrote:
On Friday, 30 June 2023 at 19:05:23 UTC, Cecil Ward wrote:
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
Decls.ordinals[ str ] = ordinal_counter++;
The problem is that it always returns ordinal== -1 from the
expression. Can you sort me out?
Impossible to tell without a complete repro, I'm afraid. The
expression, at least, looks correct at first glance.
Note that you can do `uint ordinal = Decls.ordinals.get(str,
-1);`.
Is the second argument an ‘else’ then, my friend?
Re: Bug in usage of associative array: dynamic array with string as a key
On Friday, 30 June 2023 at 20:12:08 UTC, Ali Çehreli wrote:
On 6/30/23 12:05, Cecil Ward wrote:
> I have code roughly like the following:
>
> dstring str = "name"d;
Aside: One almost never needs dstring.
> uint ordinal = (( str in Decls.ordinals ) !is null) ?
> Decls.ordinals[ str ] : -1;
>
> struct Decls
> {
> uint[ dstring] ordinals;
Do you mean 'ordinals' is 'static'? Otherwise, Decls.ordinals
does not compile.
> }
>
> //and
> Decls.ordinals[ str ] = ordinal_counter++;
Are you doing that *after* you initialize 'ordinal' as you show
here? :)
Ali
Hi Ali, ‘ordinal’ is a static initialised explicitly with zero.
Re: Bug in usage of associative array: dynamic array with string as a key
On 6/30/23 12:05, Cecil Ward wrote:
> I have code roughly like the following:
>
> dstring str = "name"d;
Aside: One almost never needs dstring.
> uint ordinal = (( str in Decls.ordinals ) !is null) ?
> Decls.ordinals[ str ] : -1;
>
> struct Decls
> {
> uint[ dstring] ordinals;
Do you mean 'ordinals' is 'static'? Otherwise, Decls.ordinals does not
compile.
> }
>
> //and
> Decls.ordinals[ str ] = ordinal_counter++;
Are you doing that *after* you initialize 'ordinal' as you show here? :)
Ali
Re: Bug in usage of associative array: dynamic array with string as a key
On Friday, 30 June 2023 at 19:05:23 UTC, Cecil Ward wrote:
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
Decls.ordinals[ str ] = ordinal_counter++;
The problem is that it always returns ordinal== -1 from the
expression. Can you sort me out?
Impossible to tell without a complete repro, I'm afraid. The
expression, at least, looks correct at first glance.
Note that you can do `uint ordinal = Decls.ordinals.get(str,
-1);`.
Bug in usage of associative array: dynamic array with string as a key
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
Decls.ordinals[ str ] = ordinal_counter++;
The problem is that it always returns ordinal== -1 from the
expression. Can you sort me out? I took this from the example
given in the language reference under arrays, testing for
membership (or similar, I forget the subssection title).
From good old printfs it seems to be the case that the array is
being populated (elsewhere) with the expected correct values.
Taking out the if doesn’t seem to help either. I don’t have a way
of examining the contents of the dynamic array directly to check
that they are actually being stored as expected, other than
seeing that that line of code is indeed being executed with the
expected values of str going in. Note that I’m using 32-bit
dstrings everywhere, not strings of bytes.
Re: looking for hint to debug a strange multi-thread bug (grpc-d-core)
UPDATE: life is too short to debug dlang built-in AA to right, let's just use HashMap from emsi_containers https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L25 ``` HashMap!(string, ServiceHandlerInterface) services; ``` After this change, the problem goes away. I think there are some bugs in the builtin AA implementation, as demo-ed in this multi-threaded program (maybe also related to GC?).
looking for hint to debug a strange multi-thread bug (grpc-d-core)
Hi,
I recently found and started playing with the grpc-d-core[1]
package, and my program structure looks like this:
https://github.com/mw66/grpc-demo/blob/master/source/main.d
If I run L64 alone (without L66 ~ 79 grpc-d part):
```
64: auto t = new Thread({fun();}).start();
```
it works fine.
If I run L66 ~ 79 grpc-d part alone (without L64), it also works
fine.
But if I run both, the program received signal SIGSEGV,
Segmentation fault at here:
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L94
with LDC, the print out of `services.keys` shows its corrupted
with some strange values.
under DMD, it fails at:
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L99
while the `services.keys` seems fine.
What puzzles me is that: these two parts of the code are actually
independent, does not know each other at all (as I just started
to add the grpc-d skeleton code with dummy returns, and no client
connected or made any rpc calls).
And the `services` defined here is a private class field:
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L21
So how can it be corrupted by `fun()`?
Any suggestions where should I look into?
Thanks.
[1] https://code.dlang.org/packages/grpc-d-core
[Issue 23442] DMD DLL GC bug when calling a function from an interface that creates a new object
https://issues.dlang.org/show_bug.cgi?id=23442 Walter Bright changed: What|Removed |Added Keywords||dll CC||bugzi...@digitalmars.com --
[Issue 16338] sort variantArray bug
https://issues.dlang.org/show_bug.cgi?id=16338 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- This seems to have been fixed. I cannot reproduce this. --
[Issue 23744] Bug/Edge case - Shorthand static if/foreach + case labels causes logical but unexpected behaviour
https://issues.dlang.org/show_bug.cgi?id=23744
--- Comment #4 from Bradley Chatha ---
Minimal reproduction:
```
void main()
{
switch(0)
{
static if (false)
case 0:
int a;
a = 0;
break;
default: break;
}
}
```
I guess case labels also directly attach onto the next statement; which
explains some other behaviour I've seen (namely the attached statement being
omitted).
--
[Issue 23744] Bug/Edge case - Shorthand static if/foreach + case labels causes logical but unexpected behaviour
https://issues.dlang.org/show_bug.cgi?id=23744 Bradley Chatha changed: What|Removed |Added Summary|Static foreach has |Bug/Edge case - Shorthand |different behaviour inside |static if/foreach + case |switch statements depending |labels causes logical but |on whether the body is in |unexpected behaviour |braces or not | --
Re: Is this a bug?
On Thursday, 16 March 2023 at 04:31:11 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote: On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote: [...] Correction. With or without comments, mostly it doesn't compile, occasionally it does! I have no idea. I can't get it to compile anymore, it must be some mistake from me. Maybe I forgot to save while modifying the code. So the `S` declared in `is` expression can contaminate the scope? Is this supposed to happen? Never mind, I just found out this is supposed to happen, `S` is supposed to be available later. https://dlang.org/spec/expression.html#is-parameter-list
Re: Is this a bug?
On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
[...]
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S));
}
```
Correction.
With or without comments, mostly it doesn't compile,
occasionally it does!
I have no idea.
I can't get it to compile anymore, it must be some mistake from
me. Maybe I forgot to save while modifying the code.
So the `S` declared in `is` expression can contaminate the scope?
Is this supposed to happen?
Re: Is this a bug?
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
[...]
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S));
}
```
Correction.
With or without comments, mostly it doesn't compile, occasionally
it does!
I have no idea.
Is this a bug?
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias`
`S` is defined here
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S)); //
Error: declaration `S` is already defined
}
```
Even though the following code compiles.
```D
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
```
Re: Is this a bug?
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias`
`S` is defined here
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S));
// Error: declaration `S` is already defined
}
```
Even though the following code compiles.
```D
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
```
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S));
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S));
}
```
[Issue 23744] Static If Compilation Differences / Attribute inference bug
https://issues.dlang.org/show_bug.cgi?id=23744 --- Comment #1 from Bradley Chatha --- Ok, it definitely seems to be its own seperate bug: https://godbolt.org/z/xKWz1h8dT --
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:37:42 UTC, Richard (Rikki) Andrew Cattermole wrote: On 03/03/2023 2:33 PM, ryuukk_ wrote: So it is a DMD bug? Yes and thanks to you I can now say that we can absolutely get rid of DllMain requirement for DLLs! glad the outcome is positive, and i apologies about earlier comments, i may have sounded a little bit rude
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:21:52 UTC, ryuukk_ wrote: I have some questions: 1. why does it work with LDC? 2. why does it work with DMD when build/link in 2 step? 3. why it doesn't work when DMD is invoked once for build/link I think these are probably coincidences and the answer can be summarized as "that's what ends up happening due to the details of the implementation". 4. is this a bug in DMD or my code is wrong? I would say the code is wrong in principle, though as you've noted it can still work in some specific circumstances. 5. if it's wrong, then why does it compile/no error? `extern(C) main` is a low-level feature, because it effectively turns off parts of the language. However, the rest of the program doesn't know that this is the case - currently the compiler simply assumes you know what you're doing. Maybe it's not OK that it's easy to use it by accident.
Re: Bug in DMD?
I added a note here: https://issues.dlang.org/show_bug.cgi?id=20737
Re: Bug in DMD?
On 03/03/2023 2:33 PM, ryuukk_ wrote: So it is a DMD bug? Yes and thanks to you I can now say that we can absolutely get rid of DllMain requirement for DLLs!
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:24:42 UTC, Richard (Rikki) Andrew
Cattermole wrote:
This works:
```d
extern(C) void main()
{
Stuff[5] temp = [
Stuff(),
Stuff(),
Stuff(),
Stuff(),
Stuff(),
];
stuffs = temp[];
stuffs[0].do_something();
}
```
```d
Stuff[] stuffs;
```
The problem here is dmd isn't initializing TLS with a value,
but TLS itself is working.
So it is a DMD bug?
Re: Bug in DMD?
This works:
```d
extern(C) void main()
{
Stuff[5] temp = [
Stuff(),
Stuff(),
Stuff(),
Stuff(),
Stuff(),
];
stuffs = temp[];
stuffs[0].do_something();
}
```
```d
Stuff[] stuffs;
```
The problem here is dmd isn't initializing TLS with a value, but TLS
itself is working.
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:11:06 UTC, Vladimir Panteleev wrote:
On Friday, 3 March 2023 at 01:07:07 UTC, ryuukk_ wrote:
I couldn't figure out dustmite, so i started from 0 and
managed to hit something:
https://github.com/ryuukk/dmd_bug
``Assertion failed: array index out of bounds, file
game\app.d, line 5``
Wich indicates probably TLS problem?
Yeah... `rt.a.stuffs` is a TLS variable. The D runtime manages
TLS. `extern(C) main` bypasses D runtime initialization.
I have some questions:
1. why does it work with LDC?
2. why does it work with DMD when build/link in 2 step?
3. why it doesn't work when DMD is invoked once for build/link
4. is this a bug in DMD or my code is wrong?
5. if it's wrong, then why does it compile/no error?
```sh
#!/usr/bin/env bash
set -e
build_dmd() {
echo "build dmd"
dmd \
-debug -g \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
stuff/rt/object.d \
game/app.d \
-of=game.exe
}
build_ldc() {
echo "build ldc"
ldc2 \
-d-debug -g \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
stuff/rt/object.d \
game/app.d \
-of=game.exe
}
build_dmd_and_link() {
echo "build dmd and link (2step)"
dmd \
-debug -g -c \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
stuff/rt/object.d \
game/app.d \
-of=game.obj
dmd \
-debug -g \
-m64 -vcolumns -betterC -w -i -i=-std -i=-core \
-Igame \
-Istuff/ \
game.obj \
-of=game.exe
}
build_ldc
./game.exe
rm game.obj game.exe
build_dmd_and_link
./game.exe
rm game.obj game.exe
build_dmd
./game.exe
rm game.obj game.exe
```
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:07:07 UTC, ryuukk_ wrote: I couldn't figure out dustmite, so i started from 0 and managed to hit something: https://github.com/ryuukk/dmd_bug ``Assertion failed: array index out of bounds, file game\app.d, line 5`` Wich indicates probably TLS problem? Yeah... `rt.a.stuffs` is a TLS variable. The D runtime manages TLS. `extern(C) main` bypasses D runtime initialization.
Re: Bug in DMD?
I couldn't figure out dustmite, so i started from 0 and managed to hit something: https://github.com/ryuukk/dmd_bug ``Assertion failed: array index out of bounds, file game\app.d, line 5`` Wich indicates probably TLS problem? This now reminds me of: https://issues.dlang.org/show_bug.cgi?id=23310 I am clueless what to do next, but at least now there is a small repro available for knowledgeable people
Re: Bug in DMD?
On 03/03/2023 10:38 AM, ryuukk_ wrote: On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew Cattermole wrote: There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with. I have no idea what does 1. mean, as for 2. do you have a link for a guide how to setup "dustmite"? When debugging, native debuggers i.e. Visual Studio, will provide you with the disassembly of the function currently being executed. Between this and other entries in the call stack, you can generally figure out what the statement is being executed just by looking at things like call instructions. The symbols there will be accurate.
Re: Bug in DMD?
On 3/2/23 15:34, ryuukk_ wrote: > the problem is not that it can run in the background, the problem is > figuring out > > 1. how to install > 2. how to setup > 3. how to run I haven't used it myself but dustmite seems to be integrated into dub. 'dub dustmite <...>' Ali
Re: Bug in DMD?
On 03/03/2023 12:34 PM, ryuukk_ wrote: 1. how to install Already is. Comes with dmd and ldc. You can also just do ``$ dub run digger -- args``. 2. how to setup > 3. how to run It is a bit of a pain but the basics is you need some sort of compilation command, list of sources and a test to confirm if it still fails. https://github.com/CyberShadow/DustMite/wiki#how-to-use-it
Re: Bug in DMD?
On Thursday, 2 March 2023 at 22:24:11 UTC, H. S. Teoh wrote: On Thu, Mar 02, 2023 at 09:55:55PM +, ryuukk_ via Digitalmars-d-learn wrote: On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote: > On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) > Andrew > Cattermole wrote: [...] > > 2. Dustmite, so we have something we can work with. > > [...] 2. do you have a link for a guide how to setup > "dustmite"? https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Dustmite automatically reduces your code to a minimal example that still exhibits the same problem, good for bug reports that are easily reproducible. Also useful if you don't want to publicly share the code for whatever reason, but still want to provide enough information so that the dmd devs can find the problem and fix it. [...] That's is not something i like doing, it should just work, i shouldn't have to debug DMD, that aint my job Dustmite can run in the background on a temporary copy of your code, you don't have to babysit it and can work on other things while it's doing its thing. T the problem is not that it can run in the background, the problem is figuring out 1. how to install 2. how to setup 3. how to run i was initially working on my game, i shouldn't have to take a 1 week break to debug dmd
Re: Bug in DMD?
On Thu, Mar 02, 2023 at 09:55:55PM +, ryuukk_ via Digitalmars-d-learn wrote: > On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote: > > On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew > > Cattermole wrote: [...] > > > 2. Dustmite, so we have something we can work with. > > > > [...] 2. do you have a link for a guide how to setup "dustmite"? https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Dustmite automatically reduces your code to a minimal example that still exhibits the same problem, good for bug reports that are easily reproducible. Also useful if you don't want to publicly share the code for whatever reason, but still want to provide enough information so that the dmd devs can find the problem and fix it. [...] > That's is not something i like doing, it should just work, i shouldn't > have to debug DMD, that aint my job Dustmite can run in the background on a temporary copy of your code, you don't have to babysit it and can work on other things while it's doing its thing. T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Re: Bug in DMD?
On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote: On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew Cattermole wrote: There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with. I have no idea what does 1. mean, as for 2. do you have a link for a guide how to setup "dustmite"? Better, can i send you a zip of my project? i'm not sure i'm willing to waste any more time trying to figure out what is wrong That's is not something i like doing, it should just work, i shouldn't have to debug DMD, that aint my job
Re: Bug in DMD?
On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew Cattermole wrote: There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with. I have no idea what does 1. mean, as for 2. do you have a link for a guide how to setup "dustmite"?
Re: Bug in DMD?
There isn't anything we can do without source. But here is what I would do in this situation: 1. Look at the assembly at the point of debug break, from here it should give you hints as to why its trying to write to dawn.assets.Resource init array. 2. Dustmite, so we have something we can work with.
Re: Bug in DMD?
It crashes with a weird message, address doesn't match the mangled name: ``C:\dev\kdom\projects\dawn\gl\glad\loader.d`` inside: ``module dawn.gl.glad.loader;`` 
Bug in DMD?
Hello, I encountered a weird issue, my program segfault when i feed DMD with my files and static libs It doesn't when i compile with LDC If i split the compile/link in 2 different steps, then all works correctly DMD (1step: ⛔): https://gist.github.com/ryuukk/f0ae2ae0c8980219c04d0c6d8678940d LDC (1step: ✅): https://gist.github.com/ryuukk/4c7706697583431389d5e2074548f7c4 DMD (2step: ✅): https://gist.github.com/ryuukk/a0373339e590ecdae91e3f05b2d81bf4 Looks like DMD is messing things up when mixing code with static libraries? Toolchains: - DMD32 D Compiler v2.102.1 - LDC - the LLVM D compiler (1.32.0-beta1):
[Issue 7680] template specialization bug
https://issues.dlang.org/show_bug.cgi?id=7680 Nick Treleaven changed: What|Removed |Added Keywords||accepts-invalid --- Comment #2 from Nick Treleaven --- With only the top overload present, the code compiles even though the argument is `Bar!int`, not `Bar!(const int)`: > template Foo26(T:Bar!(const T)) --
[Issue 7680] template specialization bug
https://issues.dlang.org/show_bug.cgi?id=7680 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- The error is: > tempspecconst.d(14): Error: template `tempspecconst.Foo26` matches more than > one template declaration: > I'm not sure whether Bar!int should match Bar!(const T) in the first place. Well this fails so I'd say no: Bar!int b; Bar!(const int) c = b; --
[Issue 23744] Static If Compilation Differences / Attribute inference bug
https://issues.dlang.org/show_bug.cgi?id=23744 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 23646] A nastier forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23646 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 23744] New: Static If Compilation Differences / Attribute inference bug
https://issues.dlang.org/show_bug.cgi?id=23744
Issue ID: 23744
Summary: Static If Compilation Differences / Attribute
inference bug
Product: D
Version: D2
Hardware: Other
OS: Mac OS X
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: brad...@chatha.dev
I'm uncertain whether this issue is mainly the "Attribute inference on
recursion" bug or instead another bug that is only manifesting itself alongside
the other bug; but essentially:
```
module test;
bool nextVaryingLengthToken() @safe
{
bool tryLexLongerOperators(alias TokenType)()
{
switch(' ')
{
/*
Comment out the first two blocks and you
will see that the error dissapears.
The only difference between the two
sets of blocks is that one has braces and
the other doesn't.
Additionally, commenting out the line `int i`
will cause the error to not appear.
It appears having _any_ sort of statement there
causes the error to show up.
*/
static if(false)
case "=":
int i;
if(tryLexLongerOperators!"=")
return true;
return true;
static if(false)
case "*":
int i3;
if(tryLexLongerOperators!"*")
return true;
return true;
static if(false)
{
case "=":
int i2;
if(tryLexLongerOperators!"=")
return true;
return true;
case "*":
int i4;
if(tryLexLongerOperators!"*")
return true;
return true;
}
default: return false;
}
}
return tryLexLongerOperators!noreturn;
}
```
It seems that `static if(false) ` will still cause the compiler to try
and evaluate the , however `static if(false) { }` causes it to not
bother.
And then since it evaluates the body it triggers the inferrence bug, which is
what makes me think this is a separate bug on its own.
However that's more just an observation rather than a truthful assertion; I'm
struggling to reproduce this outside of this particular setup.
--
[Issue 23195] Win64 function ABI bug for small non-POD arguments
https://issues.dlang.org/show_bug.cgi?id=23195 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dlang Bot --- dlang/dmd pull request #14651 "fix Issue 23195 - Win64 function ABI bug for small non-POD arguments" was merged into master: - 9a6324fa38859c5ad67592f590234cbb36ccfbb2 by Walter Bright: fix Issue 23195 - Win64 function ABI bug for small non-POD arguments https://github.com/dlang/dmd/pull/14651 --
[Issue 8901] a bug to cast from array literal to ubyte[]
https://issues.dlang.org/show_bug.cgi?id=8901 Paul Backus changed: What|Removed |Added Status|REOPENED|RESOLVED CC||snarwin+bugzi...@gmail.com Resolution|--- |INVALID --- Comment #7 from Paul Backus --- This behavior is documented in the "Casting" subsection of the "Array Literals" section of the language spec [1]: > When array literals are cast to another array type, each element of the array > is cast to the new element type. When arrays that are not literals are cast, > the array is reinterpreted as the new type, and the length is recomputed According to the git history, this paragraph was introduced in 2009 by commit 8f99bfef0. So this has been the intended, documented behavior since before this issue was first opened. [1] https://dlang.org/spec/expression.html#cast_array_literal [2] https://github.com/dlang/dlang.org/commit/8f99bfef0#diff-38fe074d968a576648917dd82d0a11b502f2a8f35e39f920e929dbd6a4d2b407 --
[Issue 8901] a bug to cast from array literal to ubyte[]
https://issues.dlang.org/show_bug.cgi?id=8901
Ate Eskola changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||ajiesk...@gmail.com
Resolution|INVALID |---
--- Comment #6 from Ate Eskola ---
I was just bitten by this one. Test case:
--
void main()
{ import std.stdio;
// Excepted: 1 on big endian machine, 0 on little endian machine
// Got: Error: array index 3 is out of bounds `[cast(ubyte)1u][0 .. 1]
(cast(ubyte[]) [1])[3].writeln();
}
--
Maybe this is behaving as intended, but if so, I'm unable to find the spec rule
that says so. Instead https://dlang.org/spec/expression.html#array_literals
says that array literals are dynamic arrays of common type of their element.
Reopening until the spec and implementation match.
--
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Dlang Bot --- dlang/dmd pull request #14838 "fix Issue 23598 - Circular reference bug with static if and eponymous…" was merged into master: - 9295ea950c3b1badc8662aff40b3ce868ff142cf by Walter Bright: fix Issue 23598 - Circular reference bug with static if and eponymous templates https://github.com/dlang/dmd/pull/14838 --
[Issue 23646] A nastier forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23646 Max Samukha changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23652 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23651 --
[Issue 23646] A nastier forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23646
--- Comment #1 from Max Samukha ---
Further reduced:
alias aliases(a...) = a;
alias Components = Dependencies!();
template Dependencies()
{
alias Dependencies = aliases!(Top.DirectDependencies);
// alias Dependencies = Top.DirectDependencies; // but this succeeds
}
struct Top
{
alias DirectDependencies = aliases!();
enum l = Components.length;
}
--
[Issue 23646] New: A nastier forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23646
Issue ID: 23646
Summary: A nastier forward reference bug
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: maxsamu...@gmail.com
alias aliases(a...) = a;
alias Components = Dependencies!Top;
template Dependencies(alias Component)
{
alias Dependencies = aliases!(Top.DirectDependencies);
// alias Dependencies = Top.DirectDependencies; // but this succeeds
}
struct Top
{
alias DirectDependencies = aliases!();
enum l = Components.length;
}
Error: template instance `onlineapp.Dependencies!(Top)` error instantiating
Moving `Components` last makes the code compile.
--
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Max Samukha changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23646 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #11 from Walter Bright --- Circular references that depend on the arms of a `static if` are always a likely source of chicken-egg problems. --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #10 from Dlang Bot --- @WalterBright created dlang/dmd pull request #14838 "fix Issue 23598 - Circular reference bug with static if and eponymous…" fixing this issue: - fix Issue 23598 - Circular reference bug with static if and eponymous templates https://github.com/dlang/dmd/pull/14838 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Walter Bright changed: What|Removed |Added Summary|Another nasty forward |Circular reference bug with |reference bug |static if and eponymous ||templates --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 Max Samukha changed: What|Removed |Added Severity|blocker |normal --- Comment #9 from Max Samukha --- (In reply to Walter Bright from comment #8) > Looking at expandMembers, perhaps this could be done in two passes - once > for the top level conditional compilation, then check oneMember, then again > for the rest. I guess doing this won't solve the general problem. Perhaps, I should humble myself and resort to other means instead of trying to get from the compiler what it can't give. --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=10616, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=20913, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=22981 --
[Issue 22981] Another forward reference bug involving a string mixin
https://issues.dlang.org/show_bug.cgi?id=22981 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23598 --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #8 from Walter Bright --- Looking at expandMembers, perhaps this could be done in two passes - once for the top level conditional compilation, then check oneMember, then again for the rest. --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #7 from Walter Bright --- Perhaps I can make this work by noticing if the `static if` member is the only member of the template, so it can be eagerly evaluated? --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #6 from Walter Bright --- What seems to be happening is the first time it goes through `template sort`, it cannot set `aliasdecl` because the two `alias sort` assignments are hidden behind conditional compilation. Hence `aliasdecl` is null. So, in semantic for `struct String` it encounters `SortedItems.length`. The `aliasdecl` is null, so `SortedItems` becomes `sort!(...)` which becomes `void` and there is no `length` for `void`. --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #5 from Walter Bright --- I suspect that when the sort template is instantiated, it is too eager to evaluate its arguments. It should just go as far as seeing String is a struct, and not attempt to semantic its contents. --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #4 from Walter Bright ---
Doing a shrink on the test case:
alias aliases(a...) = a;
template sort(alias f, a...) {
static if (a.length > 0) {
alias x = f!(a[0]);
alias sort = a;
}
else
alias sort = a;
}
alias SortedItems = sort!(isDependencyOf, String);
enum isDependencyOf(Item) = Item.DirectDependencies.length == 0;
struct String {
alias DirectDependencies = aliases!();
enum l = SortedItems.length; // no property `length`
}
If SortedItems is moved last, it compiles successfully.
--
[Issue 22981] Another forward reference bug involving a string mixin
https://issues.dlang.org/show_bug.cgi?id=22981 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #15 from Dlang Bot --- @ibuclaw created dlang/dmd pull request #14826 "dmd.aggregate: Define importAll override for AggregateDeclaration" fixing this issue: - fix Issue 22981 - Another forward reference bug involving a string mixin https://github.com/dlang/dmd/pull/14826 --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @ibuclaw created dlang/dmd pull request #14826 "dmd.aggregate: Define importAll override for AggregateDeclaration" fixing this issue: - fix Issue 23598 - Another nasty forward reference bug https://github.com/dlang/dmd/pull/14826 --
Re: Bug or feature? iota has different semantics for integer and float arguments
On Saturday, 7 January 2023 at 02:31:14 UTC, Ali Çehreli wrote: On 1/6/23 17:50, Arredondo wrote: > Would anyone volunteer to file a bug report? Me! Me! :) https://issues.dlang.org/show_bug.cgi?id=23604 Ali Thanks a lot :D Arredondo.
Re: Bug or feature? iota has different semantics for integer and float arguments
On 1/6/23 17:50, Arredondo wrote: > Would anyone volunteer to file a bug report? Me! Me! :) https://issues.dlang.org/show_bug.cgi?id=23604 Ali
Re: Bug or feature? iota has different semantics for integer and float arguments
On Saturday, 7 January 2023 at 00:52:20 UTC, Ali Çehreli wrote: Although that difference is a bug, iota does have a special floating point implementation to prevent the accumulation of floating point errors. Thank you for this clarification Ali. I appreciate the fact that there is a specialized implementation for float types in an attempt to mitigate error accumulation. After posting my previous message I became convinced that the behavior I was seeing was indeed a bug. The specialized fp implementation simply does not conform to the semantics specified in the documentation: "If begin < end && step < 0 or begin > end && step > 0 or begin == end, then an empty range is returned." The culprit is this assert in the `in` block of the fp implementation: ``` assert((end - begin) / step >= 0, "iota: incorrect startup parameters"); ``` This effectively prevents iota from ever returning an empty range. Git blame points to a commit from March 2015. It's unbelievable to me this hasn't been fixed in almost 8 years. Would anyone volunteer to file a bug report? I attempted to do it myself but I would need to create an account in the Issue Tracking System, and apparently it doesn't accept gmail addresses anymore? (facepalm). Arredondo.
Re: Bug or feature? iota has different semantics for integer and float arguments
On 1/6/23 15:23, Arredondo wrote: > then you get an exception (incorrect startup parameters). Although that difference is a bug, iota does have a special floating point implementation to prevent the accumulation of floating point errors. I mention it as item 4 here: https://www.youtube.com/watch?v=gwUcngTmKhg=634s Briefly, iota's regular popFront() is a trivial front += step but it is ++n for floating types so that front can be begin + (n * step) for them. The iota discussion starts at an earlier point in the video here: https://www.youtube.com/watch?v=gwUcngTmKhg=558s Ali
Bug or feature? iota has different semantics for integer and float arguments
Consider: ``` import std.range.iota; auto r = iota(5, 0); ``` `r` is an empty range, as it should be. But if you call: ``` auto r = iota(5.0, 0); ``` then you get an exception (incorrect startup parameters). This was unexpected, and a pain to debug. What is the rationale behind iota having different semantics depending on whether the arguments are floats or not? Arredondo.
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #2 from Max Samukha --- (In reply to Iain Buclaw from comment #1) > Related to issue 23595, and a WIP patch I have in the works fixes this test > case too. Great! Thanks! --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23595 --- Comment #1 from Iain Buclaw --- Related to issue 23595, and a WIP patch I have in the works fixes this test case too. --
[Issue 23598] New: Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598
Issue ID: 23598
Summary: Another nasty forward reference bug
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: blocker
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: maxsamu...@gmail.com
This one took me a long time to reduce. Marking it as a blocker, as I haven't
found an acceptable workaround yet.
alias aliases(a...) = a;
template sort(alias f, a...)
{
static if (a.length > 0) // (1)
{
alias x = f!(a[1]);
alias sort = a;
}
else
alias sort = a;
}
alias SortedItems = sort!(isDependencyOf, Top, String); // (2)
pragma (msg, "1: ", SortedItems);
enum isDependencyOf(Item) = Item.DirectDependencies.length == 0;
struct Top
{
alias DirectDependencies = aliases!();
}
struct String
{
alias DirectDependencies = aliases!();
pragma(msg, "2: ", SortedItems);
enum l = SortedItems.length; // (3)
static assert(is(typeof(SortedItems.length) == size_t)); // (4)
}
Error: no property `length` for `sort!(isDependencyOf, Top, String)` of type
`void`
The SortedItems tuple at (2) is (Top, String), which is correct, but at (3) it
is broken. However, at (4) it is correct again - the assert passes if (3) is
commented out. This may have something to do with the 'static if' at (1), as
the error goes away if the 'static if' and the 'else' branch are commented out.
--
[Issue 3926] opCast(bool) in classes is bug-prone
https://issues.dlang.org/show_bug.cgi?id=3926 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX Severity|normal |enhancement --- Comment #1 from RazvanN --- This is an enhancement request as the spec clearly states that for boolean operations only structs will implicitly call opCast: https://dlang.org/spec/operatoroverloading.html#boolean_operators (point 3). Indeed, if a struct is transitioned to a class this is problematic, however, other problems might appear also (for example, equality comparisons). Therefore, I don't think this is a good argument for implementing this and most likely this might silently change the behavior of a lot of code. One solution would be to have a third party tool (like D-Scanner) implement a check for class instances that are used in if conditions and also define an opCast. A warning could be issued then. --
Re: pointer escaping return scope bug?
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
p = lf.fp;
}
assert(p != null); // address escaped
}
```
There's no error with -dip1000.
I'll file this unless I overlooked something.
The state of the memory can not be guaranteed by the compiler.
That is the responsibility of the programmer. When a pointer gets
over-written the memory it was pointing to remains owne by the
program. It could be accesible by recovering the pointer. If you
want to destroy the memory there are various ways of doing this
depending on your performance needs. D has an optional garbage
collector by default.
[Issue 21151] div bug: long -5000 / size_t 2 = 9223372036854773308
https://issues.dlang.org/show_bug.cgi?id=21151 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 --
[Issue 7680] template specialization bug
https://issues.dlang.org/show_bug.cgi?id=7680 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 3926] opCast(bool) in classes is bug-prone
https://issues.dlang.org/show_bug.cgi?id=3926 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
