Re: Weird std.path API?
On Monday, 8 July 2024 at 07:29:27 UTC, aberba wrote:
On Sunday, 7 July 2024 at 15:35:36 UTC, Andrey Zherikov wrote:
On Sunday, 7 July 2024 at 14:49:52 UTC, Anonymouse wrote:
On Sunday, 7 July 2024 at 14:41:31 UTC, Andrey Zherikov wrote:
```d
import std.path;
// Error: no property `asNormaliedPath` for
`dirName("/sandbox/onlineapp.d")` of type `string`
auto p = __FILE_FULL_PATH__.dirName.asNormaliedPath;
```
`asNormalizedPath` is misspelled.
My bad, sorry :)
My blurred eyes didn't catch that
I use a plugin called Code Spell Checker in VS code...or maybe
spell checker which highlights spelling mistakes in methods and
strings.
Does it help in this case ?
Re: Weird std.path API?
On Sunday, 7 July 2024 at 15:35:36 UTC, Andrey Zherikov wrote:
On Sunday, 7 July 2024 at 14:49:52 UTC, Anonymouse wrote:
On Sunday, 7 July 2024 at 14:41:31 UTC, Andrey Zherikov wrote:
```d
import std.path;
// Error: no property `asNormaliedPath` for
`dirName("/sandbox/onlineapp.d")` of type `string`
auto p = __FILE_FULL_PATH__.dirName.asNormaliedPath;
```
`asNormalizedPath` is misspelled.
My bad, sorry :)
My blurred eyes didn't catch that
I use a plugin called Code Spell Checker in VS code...or maybe
spell checker which highlights spelling mistakes in methods and
strings.
Re: Weird std.path API?
On Sunday, 7 July 2024 at 15:35:36 UTC, Andrey Zherikov wrote:
On Sunday, 7 July 2024 at 14:49:52 UTC, Anonymouse wrote:
On Sunday, 7 July 2024 at 14:41:31 UTC, Andrey Zherikov wrote:
```d
import std.path;
// Error: no property `asNormaliedPath` for
`dirName("/sandbox/onlineapp.d")` of type `string`
auto p = __FILE_FULL_PATH__.dirName.asNormaliedPath;
```
`asNormalizedPath` is misspelled.
My bad, sorry :)
My blurred eyes didn't catch that
In first place I would have expected the spellcheck to find the
error but it looks like that does not work with UFCS.
https://issues.dlang.org/show_bug.cgi?id=9997
Re: Weird std.path API?
On Sunday, 7 July 2024 at 14:49:52 UTC, Anonymouse wrote:
On Sunday, 7 July 2024 at 14:41:31 UTC, Andrey Zherikov wrote:
```d
import std.path;
// Error: no property `asNormaliedPath` for
`dirName("/sandbox/onlineapp.d")` of type `string`
auto p = __FILE_FULL_PATH__.dirName.asNormaliedPath;
```
`asNormalizedPath` is misspelled.
My bad, sorry :)
My blurred eyes didn't catch that
Re: Weird std.path API?
On Sun, Jul 07, 2024 at 02:41:31PM +, Andrey Zherikov via
Digitalmars-d-learn wrote:
> Seems different functions in std.path do not work together:
> ```d
> import std.path;
>
> // Error: no property `asNormaliedPath` for
> `dirName("/sandbox/onlineapp.d")` of type `string`
> auto p = __FILE_FULL_PATH__.dirName.asNormaliedPath;
> ```
>
> Is this known thing or I'm doing something wrong?
Isn't it supposed to be spelled .asNormalizedPath?
T
--
IBM = I Blame Microsoft
Re: Weird std.path API?
On Sunday, 7 July 2024 at 14:41:31 UTC, Andrey Zherikov wrote:
```d
import std.path;
// Error: no property `asNormaliedPath` for
`dirName("/sandbox/onlineapp.d")` of type `string`
auto p = __FILE_FULL_PATH__.dirName.asNormaliedPath;
```
`asNormalizedPath` is misspelled.
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 RDMD error when trying to import source file from subfolder.
On Wednesday, 1 November 2023 at 16:24:04 UTC, BoQsc wrote: **Error:** ``` rdmd testimport.d testimport.d(2): Error: module `next` from file waffle\next.d must be imported with 'import next;' ``` You import 'waffle.next', but the module is inferred to be 'next'. If put `module waffle.next;` at the top of next.d, this works.
Weird RDMD error when trying to import source file from subfolder.
I'm unable to import a `.d` source file from a subfolder.
Now this happens only with `rdmd`.
The `dmd -i -run` works perfectly.
I'm currently on Windows 10 operating system.
**./testimport.d**:
```
import std;
import waffle.next;
void main(){
writeln("test", testing);
}
```
**./waffle/next.d**:
```
int testing = 5;
```
**Error:**
```
rdmd testimport.d
testimport.d(2): Error: module `next` from file waffle\next.d
must be imported with 'import next;'
```
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.
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). I did translate the library. Wow! That was a lot. It successfully builds, but does not work for long and crashes if I try to do something: it's either an assertion that fails or out of bounds array access is thrown by D. The only thing that works is pressing a button. Now I need to somehow find and fix these things. Nuclear uses flexible array members in structs and I am a bit puzzled how to handle this without a major code refactor.
Re: C to D: please help translate this weird macro
On Thursday, 21 September 2023 at 16:50:51 UTC, Imperatorn wrote: On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). When you're done, will you put it on dub? Yes, I will.
Re: C to D: please help translate this weird macro
On Thursday, 21 September 2023 at 16:28:25 UTC, Nick Treleaven
wrote:
The 1st argument of `getMember` can just be T, like the
original macro.
The 2nd argument needs to be a compile-time string.
Also the `char*` cast needs to apply to `ptr` before
subtracting the offset AFAICS.
So reordering to keep type inference of `ptr`:
```d
auto nk_container_of(T, string member, P)(P ptr)
{
return cast(T*)(cast(void*)(cast(char*)ptr -
__traits(getMember, T, member).offsetof)));
}
```
(Untested)
I will test it:)
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). When you're done, will you put it on dub?
Re: C to D: please help translate this weird macro
On Thursday, 21 September 2023 at 16:28:25 UTC, Nick Treleaven wrote: (Untested) There might be a `need this` error
Re: C to D: please help translate this weird macro
On Thursday, 21 September 2023 at 16:28:25 UTC, Nick Treleaven wrote: return cast(T*)(cast(void*)(cast(char*)ptr - __traits(getMember, T, member).offsetof))); There's a trailing `)` that needs removing. Also pretty sure it can be simplified to: return cast(T*)(cast(char*)ptr - __traits(getMember, T, member).offsetof);
Re: C to D: please help translate this weird macro
On Thursday, 21 September 2023 at 02:57:07 UTC, Ki Rill wrote:
On Thursday, 21 September 2023 at 02:23:32 UTC, Ki Rill wrote:
wrote:
[...]
Translated it to this eventually:
```D
auto nk_container_of(P, T)(P ptr, T type, const(char)* member)
{
return cast(T*)(cast(void*)(cast(char*)
(ptr - __traits(getMember, type, member).offsetof)));
}
```
The 1st argument of `getMember` can just be T, like the original
macro.
The 2nd argument needs to be a compile-time string.
Also the `char*` cast needs to apply to `ptr` before subtracting
the offset AFAICS.
So reordering to keep type inference of `ptr`:
```d
auto nk_container_of(T, string member, P)(P ptr)
{
return cast(T*)(cast(void*)(cast(char*)ptr -
__traits(getMember, T, member).offsetof)));
}
```
(Untested)
Re: C to D: please help translate this weird macro
On Thursday, 21 September 2023 at 02:23:32 UTC, Ki Rill wrote:
wrote:
[...]
Translated it to this eventually:
```D
auto nk_container_of(P, T)(P ptr, T type, const(char)* member)
{
return cast(T*)(cast(void*)(cast(char*)
(ptr - __traits(getMember, type, member).offsetof)));
}
```
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 17:14:41 UTC, Dejan Lekic
wrote:
[...]
NK_CONTAINER_OF should probably be translated to:
`cast(T*)((cast(void*)ptr - __traits(getMember, T,
member).offsetof))`
PS. I did not invent this. My original idea was far worse than
this. - It was suggested on IRC by a much cleverer D programmer
than myself - Herringway@IRC
Thanks! I translated it to this originally after looking at the
links you've provided:
```D
auto nk_container_of(P, T)(P ptr, T type, size_t member_offsetof)
{
return cast(T*)(cast(void*)(cast(char*)(1 ? (ptr) : ptr -
member_offsetof)));
}
```
`cast(T*)((cast(void*)ptr - __traits(getMember, T,
member).offsetof))`
Now, how should I wrap it like a macro? Template mixin? I'm not
that familiar with D meta programming... I shall skim through the
`D templates tutorial` for hints.
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 13:55:14 UTC, Ki Rill wrote: On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). Here is how `NK_OFFSETOF` is defined: ```c #define NK_OFFSETOF(st,m) ((nk_ptr)&(((st*)0)->m)) ``` NK_OFFSETOF is the same as D's struct `.offsetof` attribute. NK_CONTAINER_OF should probably be translated to: `cast(T*)((cast(void*)ptr - __traits(getMember, T, member).offsetof))` PS. I did not invent this. My original idea was far worse than this. - It was suggested on IRC by a much cleverer D programmer than myself - Herringway@IRC
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). My workflow when trying to port weird C code to D is to have a small C file, put an example code, and then run the preprocessor, and try to get how things are expanded Alternatively, latest version of visual studio allows you to see that in real time, you'll still have to write example code tho https://devblogs.microsoft.com/cppblog/visualize-macro-expansion-for-c/
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 13:55:14 UTC, Ki Rill wrote: On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). Here is how `NK_OFFSETOF` is defined: ```c #define NK_OFFSETOF(st,m) ((nk_ptr)&(((st*)0)->m)) ``` Looks like you are not the only one who has issue with them: https://github.com/Immediate-Mode-UI/Nuklear/issues/94 https://github.com/Immediate-Mode-UI/Nuklear/pull/309
Re: C to D: please help translate this weird macro
On Wednesday, 20 September 2023 at 13:53:08 UTC, Ki Rill wrote: Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation). Here is how `NK_OFFSETOF` is defined: ```c #define NK_OFFSETOF(st,m) ((nk_ptr)&(((st*)0)->m)) ```
C to D: please help translate this weird macro
Here is the macro: ```C #define NK_CONTAINER_OF(ptr,type,member)\ (type*)((void*)((char*)(1 ? (ptr): &((type*)0)->member) - NK_OFFSETOF(type, member))) ``` I'm trying to translate the Nuklear GUI library to D [here](https://github.com/rillki/nuklear-d/tree/nuklear-d-translation).
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: Weird template instantiation speed?
On Sunday, 9 July 2023 at 14:49:39 UTC, Steven Schveighoffer wrote: This is probably a bug somewhere, 4 seconds is too much. A reduced test case would be helpful. But I wanted to note, inside a struct template, the template name (by itself) is equivalent to the current instantiation. So just returning `BindingTempl` would be equivalent, and might not trigger this problem. See if that helps. -Steve Thank you for letting me know about being able to use `BindingTempl`, I had no idea! Unfortunately it doesn't mitigate the compile times, though. I forgot to mention, it only happens when specifying `-O` with DMD. LDC and GDC compile the same thing almost instantly. Boiling it down to a simple test is tough. If you remove a lot of components the struct template depends on then the compile time is too fast for anything to be noticeable. I think the issue is some kind of snowball-effect. If anyone wants to try to reproduce this issue: 1. Download [this exact commit](https://github.com/ichordev/bindbc-imgui/tree/65d02d68e4188250c948147a04a5820de3479a44) of the WIP BindBC-ImGui repo. (the newer commits won't compile) 2. Edit dub.selections.json to change `"bindbc-common"`'s version to `"0.0.6"`. 3. Run: ``` dmd -extern-std=c++11 -lib -O -version=BindImGui_Static -Isource/ -I~/.dub/packages/bindbc-common/0.0.6/bindbc-common/source/ source/bindbc/imgui/config.d source/bindbc/imgui/package.d source/imgui/impl.d source/imgui/package.d -v ``` 4. Now, remove `-O` from the dmd command. Blink and you'll miss it compiling!
Re: Weird template instantiation speed?
On 7/9/23 7:54 AM, IchorDev wrote: While working on some new bindings, I've discovered that if `opAssign` in a struct template "`BindingTempl(T)`" has the return type "`BindingTempl!T` then it adds about 4 seconds to the compile time per instantiation of `BindingTempl`. The added compile time is much lower if a function other than `opAssign` returns `BindingTempl!T`. Is opAssign a particularly bad operator to overload in templates or something? This is probably a bug somewhere, 4 seconds is too much. A reduced test case would be helpful. But I wanted to note, inside a struct template, the template name (by itself) is equivalent to the current instantiation. So just returning `BindingTempl` would be equivalent, and might not trigger this problem. See if that helps. -Steve
Weird template instantiation speed?
While working on some new bindings, I've discovered that if `opAssign` in a struct template "`BindingTempl(T)`" has the return type "`BindingTempl!T` then it adds about 4 seconds to the compile time per instantiation of `BindingTempl`. The added compile time is much lower if a function other than `opAssign` returns `BindingTempl!T`. Is opAssign a particularly bad operator to overload in templates or something?
[Issue 23950] Weird backend fail with noreturn type - cod1.d(4027): Assertion failure
https://issues.dlang.org/show_bug.cgi?id=23950 RazvanN changed: What|Removed |Added Keywords||backend, ice CC||razvan.nitu1...@gmail.com Severity|normal |critical --
[Issue 23950] Weird backend fail with noreturn type - cod1.d(4027): Assertion failure
https://issues.dlang.org/show_bug.cgi?id=23950
--- Comment #1 from m...@ernestocastellotti.it ---
The absurd thing is that instead this code compiles and works correctly:
import core.stdc.stdlib;
void main() {
auto foo = (false != true) && true || abort();
}
This looks just like a bad bug in the backend depending on what the code from
the frontend
--
[Issue 23950] New: Weird backend fail with noreturn type - cod1.d(4027): Assertion failure
https://issues.dlang.org/show_bug.cgi?id=23950
Issue ID: 23950
Summary: Weird backend fail with noreturn type - cod1.d(4027):
Assertion failure
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: m...@ernestocastellotti.it
The DMD backend fails with this code:
import core.stdc.stdlib;
void main() {
auto foo = false && true || abort();
}
This is the error message:
core.exception.AssertError@src/dmd/backend/cod1.d(4027): Assertion failure
??:? _d_assertp [0x9884d4]
src/dmd/backend/cod1.d:4027 _Z8funccallR11CodeBuilderP4elemjjPjjb [0x8ffd32]
src/dmd/backend/cod1.d:3749 _Z6cdfuncR11CodeBuilderP4elemPj [0x8fef41]
src/dmd/backend/cgcod.d:2738 _Z7codelemR11CodeBuilderP4elemPjj [0x8f510a]
src/dmd/backend/cod2.d:2082 _Z5cdnotR11CodeBuilderP4elemPj [0x90c4d3]
src/dmd/backend/cgcod.d:2738 _Z7codelemR11CodeBuilderP4elemPjj [0x8f510a]
src/dmd/backend/cgcod.d:2868 _Z8scodelemR11CodeBuilderP4elemPjjb [0x8f555c]
src/dmd/backend/cod4.d:709 _Z4cdeqR11CodeBuilderP4elemPj [0x8bec0b]
src/dmd/backend/cgcod.d:2738 _Z7codelemR11CodeBuilderP4elemPjj [0x8f510a]
src/dmd/backend/cgen.d:198 _Z10gencodelemR11CodeBuilderP4elemPjb [0x940c65]
src/dmd/backend/cod3.d:960
_Z14outblkexitcodeR11CodeBuilderP5blockRiPKcPP6Symbolj [0x917fa3]
src/dmd/backend/cgcod.d:1455 _Z8blcodgenP5block [0x8f2efc]
src/dmd/backend/cgcod.d:291 _Z6codgenP6Symbol [0x8f059d]
src/dmd/backend/dout.d:1034 _Z10writefunc2P6Symbol [0x8a457e]
src/dmd/backend/dout.d:853 _Z9writefuncP6Symbol [0x8a3ed6]
src/dmd/glue.d:1199 _Z25FuncDeclaration_toObjFileP15FuncDeclarationb [0x842a4f]
src/dmd/toobj.d:309 _ZN9toObjFile9ToObjFile5visitEP15FuncDeclaration [0x85c1a1]
src/dmd/func.d:2991 _ZN15FuncDeclaration6acceptEP7Visitor [0x767119]
src/dmd/toobj.d:1021 _Z9toObjFileP7Dsymbolb [0x85c108]
src/dmd/glue.d:529 _Z10genObjFileP6Moduleb [0x840b71]
src/dmd/glue.d:122 void dmd.glue.generateCodeAndWrite(dmd.dmodule.Module[],
const(char)*[], const(char)[], const(char)[], bool, bool, bool, bool, bool)
[0x83f39c]
src/dmd/mars.d:582 int dmd.mars.tryMain(ulong, const(char)**, ref
dmd.globals.Param) [0x64fe08]
src/dmd/mars.d:966 _Dmain [0x651354]
LDC and GDC have no problem with this code so the problem must be related
exclusively to the DMD backend, i have no idea what could be causing it someone
with backend experience should look into it.
--
Re: A weird example of .toUTF16z concatination side-effects in wcsncat
On Thursday, 7 April 2022 at 12:51:26 UTC, Stanislav Blinov wrote:
On Thursday, 7 April 2022 at 10:50:35 UTC, BoQsc wrote:
wchar_t* clang_string = cast(wchar_t *)"AA";
You're witnessing undefined behavior. "AA" is a string
literal and is stored in the data segment. Mere cast to
wchar_t* does not make writing through that pointer legal.
Moreover, even if it was legal to write through it, that alone
wouldn't be sufficient. From documentation of `wcsncat`:
The behavior is undefined if the destination array is not
large enough for the contents of both str and dest and the
terminating null wide character.
`wcsncat` does not allocate memory, it expects you to provide a
sufficiently large mutable buffer. For example, like this:
```d
// ...
auto cls = new wchar_t[256];
cls[] = 0;
cls[0..10] = 'A';
wchar_t* clang_string = cls.ptr;
// ...
```
That is correct, the results are satisfying. I believe this
thread is resolved.
```
import std.stdio;
@system void main(){
import std.utf: toUTF16z, toUTF16;
import core.stdc.wchar_ : wcsncat, wcslen, wprintf;
import core.stdc.stdlib : wchar_t;
import core.sys.windows.winnt : LPCWSTR;
auto cls = new wchar_t[256];
cls[] = 0;
cls[0..10] = 'A';
wchar_t* clang_string = cls.ptr;
//wchar_t* clang_string = cast(wchar_t *)"AA";
wstring dlang_string = "BB"w; //< NEW,
same results
LPCWSTR winpointer_to_string = "CC";
wcsncat(clang_string, dlang_string.toUTF16z,
wcslen(dlang_string.toUTF16z));
// String output: AABB
wcsncat(clang_string, winpointer_to_string,
wcslen(winpointer_to_string));
// String output: AABBCC
// Expected string: AABBCC
wprintf(clang_string);
// String output: AABBCC
// Expected string: AABBCC
}
```
Re: A weird example of .toUTF16z concatination side-effects in wcsncat
On Thursday, 7 April 2022 at 10:50:35 UTC, BoQsc wrote: wchar_t* clang_string = cast(wchar_t *)"AA"; You're witnessing undefined behavior. "AA" is a string literal and is stored in the data segment. Mere cast to wchar_t* does not make writing through that pointer legal. Moreover, even if it was legal to write through it, that alone wouldn't be sufficient. From documentation of `wcsncat`: The behavior is undefined if the destination array is not large enough for the contents of both str and dest and the terminating null wide character. `wcsncat` does not allocate memory, it expects you to provide a sufficiently large mutable buffer. For example, like this: ```d // ... auto cls = new wchar_t[256]; cls[] = 0; cls[0..10] = 'A'; wchar_t* clang_string = cls.ptr; // ... ```
Re: A weird example of .toUTF16z concatination side-effects in wcsncat
On Thursday, 7 April 2022 at 11:03:39 UTC, Tejas wrote:
On Thursday, 7 April 2022 at 10:50:35 UTC, BoQsc wrote:
Here I try to concatenate three character strings using
`wcsncat()`.
[...]
Maybe try using `wstring` instead of string? Also use the `w`
postfix
```d
wstring dlang_string = "BBB"w;
I can't test because I'm not on my PC and I don't use Windows
Exactly same results. `AA`
```
import std.stdio;
@system void main(){
import std.utf: toUTF16z, toUTF16;
import core.stdc.wchar_ : wcsncat, wcslen, wprintf;
import core.stdc.stdlib : wchar_t;
import core.sys.windows.winnt : LPCWSTR;
wchar_t* clang_string = cast(wchar_t *)"AA";
wstring dlang_string = "BBB"w; //< NEW,
same results
LPCWSTR winpointer_to_string = "CC";
wcsncat(clang_string, dlang_string.toUTF16z,
wcslen(dlang_string.toUTF16z));
// String output: AABBB
wcsncat(clang_string, winpointer_to_string,
wcslen(winpointer_to_string));
// String output: AA
// Expected string: AABBBCC
wprintf(clang_string);
// String output: AA
// Expected string: AABBBCC
}
```
Re: A weird example of .toUTF16z concatination side-effects in wcsncat
On Thursday, 7 April 2022 at 10:50:35 UTC, BoQsc wrote: Here I try to concatenate three character strings using `wcsncat()`. [...] Maybe try using `wstring` instead of string? Also use the `w` postfix ```d wstring dlang_string = "BBB"w; I can't test because I'm not on my PC and I don't use Windows
A weird example of .toUTF16z concatination side-effects in wcsncat
Here I try to concatenate three character strings using
`wcsncat()`.
`clang_string` AA
`dlang_string` BBB
`winpointer_to_string` CC
```
import std.stdio;
@system void main(){
import std.utf: toUTF16z, toUTF16;
import core.stdc.wchar_ : wcsncat, wcslen, wprintf;
import core.stdc.stdlib : wchar_t;
import core.sys.windows.winnt : LPCWSTR;
wchar_t* clang_string = cast(wchar_t *)"AA";
string dlang_string = "BBB";
LPCWSTR winpointer_to_string = "CC";
wcsncat(clang_string, dlang_string.toUTF16z,
wcslen(dlang_string.toUTF16z));
// String output: AABBB
wcsncat(clang_string, winpointer_to_string,
wcslen(winpointer_to_string));
// String output: AA
// Expected string: AABBBCC
wprintf(clang_string);
// String output: AA
// Expected string: AABBBCC
}
```
**Problem:**
Any *following concatenated string* after "`wcsncat()`
concatenation of `dlang_string.toUTF16z` string", happen to not
be printed and gets overwritten.
**The Expected output:**
I was expecting the `wprintf()` **result** to be
`AABBBCC`
The `wprintf() ` **result** I've received is this:
`AA`
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/23/21 3:30 PM, apz28 wrote: On Friday, 23 July 2021 at 18:44:47 UTC, Steven Schveighoffer wrote: On 7/22/21 7:43 PM, apz28 wrote: In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called. The -debug build with passing unit-tests so no problem there. The -release build is having problem. After make change to accommodate it, it takes forever to build. I started it yesterday 11AM and it is still compiling now (more than a day already.) It takes a full 100% core and peek memory usage is 2.2GB. The hard-drive is SSD That is a separate problem. That build is hung, and you likely have found a bug in the compiler. I have never seen a build last more than a few minutes at the most. If the code you posted is not crashing with a segfault, then it's possible there is a code generation issue. I still believe you have your check backwards. -Steve
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/23/21 12:30 PM, apz28 wrote: > The -debug build with passing unit-tests so no problem there. > The -release build is having problem. After make change to accommodate > it, it takes forever to build. I started it yesterday 11AM and it is > still compiling now (more than a day already.) It takes a full 100% core > and peek memory usage is 2.2GB. The hard-drive is SSD There is definitely something wrong with the compiler. That build time is ridiculously high. Ali
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Friday, 23 July 2021 at 18:44:47 UTC, Steven Schveighoffer wrote: On 7/22/21 7:43 PM, apz28 wrote: In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called. -Steve The -debug build with passing unit-tests so no problem there. The -release build is having problem. After make change to accommodate it, it takes forever to build. I started it yesterday 11AM and it is still compiling now (more than a day already.) It takes a full 100% core and peek memory usage is 2.2GB. The hard-drive is SSD
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/22/21 7:43 PM, apz28 wrote: FbConnection is a class, FbXdrReader is a struct and for this call, response.data is not null & its' length will be greater than zero and FbConnection is not being used. So why DMD try to evaluate at compiled time hence error 1. Should not evaluate at compile time for this function call/construct 2. The error message is missing proper line # or nothing related to the module displayed in error message https://github.com/apz28/dlang/blob/main/source/pham/db/db_fbbuffer.d#L527 I have a feeling that line is backwards. It says: if the buffer has length, ignore it and use the connection, otherwise use the (empty) buffer data. So perhaps this is actually a real error that is being flagged (because it's inlined)? In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called. -Steve
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Thursday, 22 July 2021 at 18:56:43 UTC, Steven Schveighoffer wrote: On 7/22/21 2:38 PM, apz28 wrote: On Wednesday, 21 July 2021 at 20:39:54 UTC, Dukc wrote: On Wednesday, 21 July 2021 at 14:15:51 UTC, Steven Schveighoffer wrote: 2. It's hard for me to see where the null dereference would be in that function (the `bool` implementation is pretty simple). DMD complains about dereferences in three different lines. I suspect it's `this` reference that is `null`. Look like DMD has some bug. If I changed this line https://github.com/apz28/dlang/blob/02989b94bfe306d723f2780e010c61f71f873cbe/source/pham/db/db_fbdatabase.d#L148 from: auto reader = FbXdrReader(null, response.data); to: auto reader = FbXdrReader(fbConnection, response.data); then the error go away. FbXdrReader constructor allows to accept null for that parameter. Is it "safe" means not allow to pass null? I don't know what an FbConnection is, but it looks like you call something on it. Your code is immense, and github search really *really* sucks. So I can't get better information. But if it's a class, and that is a normal member, it is indeed dereferencing a null pointer. -Steve FbConnection is a class, FbXdrReader is a struct and for this call, response.data is not null & its' length will be greater than zero and FbConnection is not being used. So why DMD try to evaluate at compiled time hence error 1. Should not evaluate at compile time for this function call/construct 2. The error message is missing proper line # or nothing related to the module displayed in error message https://github.com/apz28/dlang/blob/main/source/pham/db/db_fbbuffer.d#L527
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/22/21 2:38 PM, apz28 wrote: On Wednesday, 21 July 2021 at 20:39:54 UTC, Dukc wrote: On Wednesday, 21 July 2021 at 14:15:51 UTC, Steven Schveighoffer wrote: 2. It's hard for me to see where the null dereference would be in that function (the `bool` implementation is pretty simple). DMD complains about dereferences in three different lines. I suspect it's `this` reference that is `null`. Look like DMD has some bug. If I changed this line https://github.com/apz28/dlang/blob/02989b94bfe306d723f2780e010c61f71f873cbe/source/pham/db/db_fbdatabase.d#L148 from: auto reader = FbXdrReader(null, response.data); to: auto reader = FbXdrReader(fbConnection, response.data); then the error go away. FbXdrReader constructor allows to accept null for that parameter. Is it "safe" means not allow to pass null? I don't know what an FbConnection is, but it looks like you call something on it. Your code is immense, and github search really *really* sucks. So I can't get better information. But if it's a class, and that is a normal member, it is indeed dereferencing a null pointer. -Steve
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 20:39:54 UTC, Dukc wrote: On Wednesday, 21 July 2021 at 14:15:51 UTC, Steven Schveighoffer wrote: 2. It's hard for me to see where the null dereference would be in that function (the `bool` implementation is pretty simple). -Steve DMD complains about dereferences in three different lines. I suspect it's `this` reference that is `null`. Look like DMD has some bug. If I changed this line https://github.com/apz28/dlang/blob/02989b94bfe306d723f2780e010c61f71f873cbe/source/pham/db/db_fbdatabase.d#L148 from: auto reader = FbXdrReader(null, response.data); to: auto reader = FbXdrReader(fbConnection, response.data); then the error go away. FbXdrReader constructor allows to accept null for that parameter. Is it "safe" means not allow to pass null?
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 14:15:51 UTC, Steven Schveighoffer wrote: 2. It's hard for me to see where the null dereference would be in that function (the `bool` implementation is pretty simple). -Steve DMD complains about dereferences in three different lines. I suspect it's `this` reference that is `null`.
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/21/21 7:56 AM, apz28 wrote:
On Wednesday, 21 July 2021 at 11:52:39 UTC, apz28 wrote:
On Wednesday, 21 July 2021 at 04:52:44 UTC, Mathias LANG wrote:
It seems the compiler is doing extra analysis and seeing that a null
pointer is being dereferenced. Can you provide the code for
"pham\db\db_skdatabase.d" at L138 through 140 ?
```d
package(pham.db): // Line# 133
final DbReadBuffer acquireSocketReadBuffer(size_t capacity =
DbDefaultSize.socketReadBufferLength) nothrow @safe
{
version (TraceFunction) dgFunctionTrace();
if (_socketReadBuffer is null)
_socketReadBuffer = createSocketReadBuffer(capacity);
return _socketReadBuffer;
}
```
The entire codes is available from github
https://github.com/apz28/dlang/blob/main/source/pham/db/db_skdatabase.d#L138
1. That filename is totally wrong, or the function name is totally
wrong. ddemangle says the function is `@safe bool[]
pham.db.fbdatabase.FbArray.readArrayImpl!(bool).readArrayImpl(pham.db.database.DbNameColumn)`
which seems to be located
[here](https://github.com/apz28/dlang/blob/02989b94bfe306d723f2780e010c61f71f873cbe/source/pham/db/db_fbdatabase.d#L142)
But the line numbers also don't match. maybe an inlining issue?
2. It's hard for me to see where the null dereference would be in that
function (the `bool` implementation is pretty simple).
-Steve
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 03:25:03 UTC, apz28 wrote: VisualD project - Any hint to work around DMD version: DMD32 D Compiler v2.096.0-rc.1-dirty Copyright (C) 1999-2021 by The D Language Foundation, All Rights Reserved written by Walter Bright Failed Build Command line: dmd -release -m32mscoff -O -inline -dip25 -dip1000 -preview=fixAliasThis -X -Xf"Win32\Release\db_library.json" -c -of"Win32\Release\db_library.obj" @Win32\Release\db_library.build.rsp with below error message: ..\..\pham\db\db_skdatabase.d(140): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(139): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(138): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb The problem here is not actually -release but -O. -O will check for null derefences in your code when using @safe I believe. I didn't inspect your code much further, as I'm short on time right now, but you should have a starting point now at least.
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 11:52:39 UTC, apz28 wrote:
On Wednesday, 21 July 2021 at 04:52:44 UTC, Mathias LANG wrote:
It seems the compiler is doing extra analysis and seeing that
a null pointer is being dereferenced. Can you provide the code
for "pham\db\db_skdatabase.d" at L138 through 140 ?
```d
package(pham.db): // Line# 133
final DbReadBuffer acquireSocketReadBuffer(size_t
capacity = DbDefaultSize.socketReadBufferLength) nothrow @safe
{
version (TraceFunction) dgFunctionTrace();
if (_socketReadBuffer is null)
_socketReadBuffer =
createSocketReadBuffer(capacity);
return _socketReadBuffer;
}
```
The entire codes is available from github
https://github.com/apz28/dlang/blob/main/source/pham/db/db_skdatabase.d#L138
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 04:52:44 UTC, Mathias LANG wrote:
It seems the compiler is doing extra analysis and seeing that a
null pointer is being dereferenced. Can you provide the code
for "pham\db\db_skdatabase.d" at L138 through 140 ?
```d
package(pham.db): // Line# 133
final DbReadBuffer acquireSocketReadBuffer(size_t
capacity = DbDefaultSize.socketReadBufferLength) nothrow @safe
{
version (TraceFunction) dgFunctionTrace();
if (_socketReadBuffer is null)
_socketReadBuffer =
createSocketReadBuffer(capacity);
return _socketReadBuffer;
}
```
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 03:25:03 UTC, apz28 wrote: with below error message: ..\..\pham\db\db_skdatabase.d(140): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(139): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(138): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb It seems the compiler is doing extra analysis and seeing that a null pointer is being dereferenced. Can you provide the code for "pham\db\db_skdatabase.d" at L138 through 140 ?
How to Fix Weird Build Failure with "-release" but OK with "-debug"?
VisualD project - Any hint to work around DMD version: DMD32 D Compiler v2.096.0-rc.1-dirty Copyright (C) 1999-2021 by The D Language Foundation, All Rights Reserved written by Walter Bright Failed Build Command line: dmd -release -m32mscoff -O -inline -dip25 -dip1000 -preview=fixAliasThis -X -Xf"Win32\Release\db_library.json" -c -of"Win32\Release\db_library.obj" @Win32\Release\db_library.build.rsp with below error message: ..\..\pham\db\db_skdatabase.d(140): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(139): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(138): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb
Re: Visual D showing weird errors
On Wednesday, 28 April 2021 at 06:06:47 UTC, Rainer Schuetze wrote: On 26/04/2021 20:22, Imperatorn wrote: On Monday, 26 April 2021 at 17:37:26 UTC, Rainer Schuetze wrote: On 26/04/2021 10:00, Raimondo Mancino wrote: [...] The problem is that the semantic engine used by Visual D is working with the DMD frontend of 2.095, but "noreturn" is a new language feature introduced with 2.096. You can filter out messages from "Intellisense" in the Error List window by selecting to show "Build only". I hope I can supply a new version of Visual D with an updated semantic engine soon. That would be awesome There is a new version 1.1.1 available now with the semantic engine updated to dmd 2.096.1. Splendid, thanks! Will try it out soon
Re: Visual D showing weird errors
On 26/04/2021 20:22, Imperatorn wrote: > On Monday, 26 April 2021 at 17:37:26 UTC, Rainer Schuetze wrote: >> >> On 26/04/2021 10:00, Raimondo Mancino wrote: >>> [...] >> >> The problem is that the semantic engine used by Visual D is working >> with the DMD frontend of 2.095, but "noreturn" is a new language >> feature introduced with 2.096. >> >> You can filter out messages from "Intellisense" in the Error List >> window by selecting to show "Build only". >> >> I hope I can supply a new version of Visual D with an updated semantic >> engine soon. > > That would be awesome There is a new version 1.1.1 available now with the semantic engine updated to dmd 2.096.1.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 17:37:26 UTC, Rainer Schuetze wrote: On 26/04/2021 10:00, Raimondo Mancino wrote: [...] The problem is that the semantic engine used by Visual D is working with the DMD frontend of 2.095, but "noreturn" is a new language feature introduced with 2.096. You can filter out messages from "Intellisense" in the Error List window by selecting to show "Build only". I hope I can supply a new version of Visual D with an updated semantic engine soon. That would be awesome
Re: Visual D showing weird errors
On 26/04/2021 10:00, Raimondo Mancino wrote: > Hello, I'm new to the language; I just started learning it a few months > ago. I'm doing okay with it, I find it very versatile and fast to learn. > I come from Java and C/C++ and I think D solves tons of problems I had > with these. > > I was trying the Visual D extension to Visual Studio, but after the > first code generation (DLL library, x86 & x64 both checked), I get this > weird error: > > ``` > C:\D\dmd2\src\druntime\import\core\sys\windows\dll.d: > \object.d(18): can only `*` a pointer, not a `typeof(null)` > ``` The problem is that the semantic engine used by Visual D is working with the DMD frontend of 2.095, but "noreturn" is a new language feature introduced with 2.096. You can filter out messages from "Intellisense" in the Error List window by selecting to show "Build only". I hope I can supply a new version of Visual D with an updated semantic engine soon.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 15:54:36 UTC, Adam D. Ruppe wrote: Do you have a separate object.d in your current directory? That can cause all kinds of weird errors. Otherwise I suspect this is a conflict between two versions of the compiler. If you had one installed before then updated it or maybe if visual d installed a different one, this could be a problem. So either some old files were left behind or there's two copies installed and VS is running one but pointing at the other. Or something. The noreturn thing is relatively new making me think this might be the case. The compiler and stdlib are ridiculously tightly coupled so any version mismatch can cause trouble. just guessing though. Actually, you were right. I was about to write that updating Visual D to the latest version worked. I'm sorry for this silly thread. Thank you all for your help and suggestions.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 08:00:08 UTC, Raimondo Mancino wrote: C:\D\dmd2\src\druntime\import\core\sys\windows\dll.d: \object.d(18): can only `*` a pointer, not a `typeof(null)` Do you have a separate object.d in your current directory? That can cause all kinds of weird errors. Otherwise I suspect this is a conflict between two versions of the compiler. If you had one installed before then updated it or maybe if visual d installed a different one, this could be a problem. So either some old files were left behind or there's two copies installed and VS is running one but pointing at the other. Or something. The noreturn thing is relatively new making me think this might be the case. The compiler and stdlib are ridiculously tightly coupled so any version mismatch can cause trouble. just guessing though.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 14:17:34 UTC, Imperatorn wrote: Also, be sure to join on Discord as well (https://discord.gg/bMZk9Q4) if you're not already there! Thank you, I think I'll join.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 10:42:54 UTC, Mike Parker wrote: (According to -v: DMD64 D Compiler v2.096.0-dirty) That's actually normal for the Windows versions. I'm not sure where it comes from, but it's always there. Ouuu, that's bad advertising, isn't it? Who wants to use dirty software, it could infect your computer... :-O
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 11:03:19 UTC, Raimondo Mancino wrote: On Monday, 26 April 2021 at 10:44:14 UTC, Mike Parker wrote: You might try to build outside of VS and see if you get the same errors. The weird thing is that I get these errors just in the errors frame, but building works just fine without errors. If I run devenv.exe directly on the solution, or select "build" from the menu, it builds fine; just, I don't get autocompletion or go-to-definition for some symbols. Debugging works as well (although I see mangled symbol names, but I guess it's how it is supposed to work). Also, be sure to join on Discord as well (https://discord.gg/bMZk9Q4) if you're not already there!
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 11:03:19 UTC, Raimondo Mancino wrote: On Monday, 26 April 2021 at 10:44:14 UTC, Mike Parker wrote: You might try to build outside of VS and see if you get the same errors. The weird thing is that I get these errors just in the errors frame, but building works just fine without errors. If I run devenv.exe directly on the solution, or select "build" from the menu, it builds fine; just, I don't get autocompletion or go-to-definition for some symbols. Debugging works as well (although I see mangled symbol names, but I guess it's how it is supposed to work). Might be related to recent work on the semantic engine.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 10:44:14 UTC, Mike Parker wrote: You might try to build outside of VS and see if you get the same errors. The weird thing is that I get these errors just in the errors frame, but building works just fine without errors. If I run devenv.exe directly on the solution, or select "build" from the menu, it builds fine; just, I don't get autocompletion or go-to-definition for some symbols. Debugging works as well (although I see mangled symbol names, but I guess it's how it is supposed to work).
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 10:40:44 UTC, Johann Lermer wrote: On Monday, 26 April 2021 at 08:58:25 UTC, Raimondo Mancino wrote: According to -v: DMD64 D Compiler v2.096.0-dirty Well, that says it all, doesn't it? I'm not familiar with the windows versions, but that doesn't seem to be an offical release - at least I never had a dmd2 that claimed to be dirty ;-) That's actually normal for the Windows versions. I'm not sure where it comes from, but it's always there.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 08:00:08 UTC, Raimondo Mancino wrote: Since these are thrown by the standard library, I suspect this could be a bug; but maybe I'm just missing something? Thank you for your help. You might try to build outside of VS and see if you get the same errors.
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 08:58:25 UTC, Raimondo Mancino wrote: According to -v: DMD64 D Compiler v2.096.0-dirty Well, that says it all, doesn't it? I'm not familiar with the windows versions, but that doesn't seem to be an offical release - at least I never had a dmd2 that claimed to be dirty ;-)
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 08:40:01 UTC, Imperatorn wrote: On Monday, 26 April 2021 at 08:00:08 UTC, Raimondo Mancino wrote: Hello, I'm new to the language; I just started learning it a few months ago. I'm doing okay with it, I find it very versatile and fast to learn. I come from Java and C/C++ and I think D solves tons of problems I had with these. [...] What compiler and version are you using? According to -v: DMD64 D Compiler v2.096.0-dirty
Re: Visual D showing weird errors
On Monday, 26 April 2021 at 08:00:08 UTC, Raimondo Mancino wrote: Hello, I'm new to the language; I just started learning it a few months ago. I'm doing okay with it, I find it very versatile and fast to learn. I come from Java and C/C++ and I think D solves tons of problems I had with these. [...] What compiler and version are you using?
Visual D showing weird errors
Hello, I'm new to the language; I just started learning it a few months ago. I'm doing okay with it, I find it very versatile and fast to learn. I come from Java and C/C++ and I think D solves tons of problems I had with these. I was trying the Visual D extension to Visual Studio, but after the first code generation (DLL library, x86 & x64 both checked), I get this weird error: ``` C:\D\dmd2\src\druntime\import\core\sys\windows\dll.d: \object.d(18): can only `*` a pointer, not a `typeof(null)` ``` So I opened the object.d in VS and apparently, this is the line of code it's yelling at: ``` alias noreturn = typeof(*null); /// bottom type ``` I am unsure how to solve this problem. It doesn't appear to happen if I choose "console application" instead of "DLL Library". Although, errors do appear if I try to inspect, for example, stdio.d: ``` Error: C:\D\dmd2\src\druntime\import\object.d(3460): template instance `object._dup!(const(char), immutable(char))` error instantiating C:\D\dmd2\src\druntime\import\object.d(3438): instantiated from here: `_trustedDup!(const(char), immutable(char))` C:\D\dmd2\src\phobos\std\exception.d(516): instantiated from here: `idup!(const(char))` C:\D\dmd2\src\phobos\std\exception.d(437): instantiated from here: `bailOut!(Exception)` --> instantiated from here: `enforce!(void*)` ``` and also: ``` Error: C:\D\dmd2\src\phobos\std\exception.d(437): template instance `std.exception.bailOut!(ErrnoException)` error instantiating --> instantiated from here: `enforce!(shared(_iobuf)*)` ``` and others. Since these are thrown by the standard library, I suspect this could be a bug; but maybe I'm just missing something? Thank you for your help.
Re: weird formattedRead
On 4/9/21 11:17 AM, Berni44 wrote: > I'm on reworking completely the docs of `std.format`. Awesome! :) Ali
Re: weird formattedRead
On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote: valid '1/1/1': 0001-Jan-01 00:00:00 <<< see here [...] Is space a special char for `formattedRead` and it simple stop parse without throwing exception if not found space (that represented in fmt string)? Have `formattedRead` any other special chars? Or it's bug? It's a (at least to me) known bug (I haven't taken the time to report it yet; found it a few days ago, when I reworked the docs). `formattedRead` treats space sometimes special and sometimes not, which (obviously) may lead to strange behavior, like it does here. If you like, you can [report this one](https://issues.dlang.org/enter_bug.cgi); I'll probably will care about it in a few weeks/months (I first want to fix the `formattedWrite` bugs and finish implementing formatting floating point numbers without calling `snprintf`.) On Friday, 9 April 2021 at 16:39:30 UTC, Ali Çehreli wrote: P.S. I can't check whether the D standard library documentation includes that information because the documentation looks very different and very skimpy to me at this time. There is nothing on format characters on formattedRead's documentation. (?) When using the `stable` docs you still should get, what you are used to. But I guess, you used the `master` docs and looked at `formattedWrite` where the information used to be. Since about three weeks I'm on reworking completely the docs of `std.format`. Before that, the module has been split in several submodules (package, read, write, specs). Meanwhile I moved the docs you know from `formattedWrite` to [package](https://dlang.org/phobos-prerelease/std_format.html) (but yet not reworked completely, because the review process takes some time and I try to verify everything I state in the new docs in the source code). For [`formattedRead`](https://dlang.org/phobos-prerelease/std_format_read.html#.formattedRead) and [reading in general](https://dlang.org/phobos-prerelease/std_format_read.html), the new docs are already finished. Feedback is welcome.
Re: weird formattedRead
On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote: Is space a special char for `formattedRead` and it simple stop parse without throwing exception if not found space (that represented in fmt string)? Have `formattedRead` any other special chars? Or it's bug? I think it's a bug: The char 0x20 is meant to be skipped till end of the string or a parseable char in the format string by the function readUpToNextSpec(). If the function found a whitespace in the input string, it's fine and skipped as long there is another whitespace char. But if the input string range is already done, it also does just nothing anymore. For other chars if would throw the 'Cannot find character' exception. But the source declared this as "backwards compatibility": ``` string s = " 1.2 3.4 "; double x, y, z; assert(formattedRead(s, " %s %s %s ", , , ) == 2); assert(s.empty); assert(approxEqual(x, 1.2)); assert(approxEqual(y, 3.4)); assert(isNaN(z)); ``` So it seems to be a desired behaviour.
Re: weird formattedRead
On 4/9/21 9:11 AM, Oleg B wrote: > Is space a special char for `formattedRead` and it simple stop parse > without throwing exception if not found space Yes: The space character means "zero or more white space". Ali P.S. I can't check whether the D standard library documentation includes that information because the documentation looks very different and very skimpy to me at this time. There is nothing on format characters on formattedRead's documentation. (?)
weird formattedRead
Hello, I have some doubts about working `formattedRead` with
space chars.
Example:
```d
import std : formattedRead, DateTime, stderr, each;
DateTime parseDT(string str)
{
int d,mo,y, h,m,s;
formattedRead!"%d/%d/%d %d:%d:%d"(str, d,mo,y, h,m,s);
return DateTime(y,mo,d, h,m,s);
}
void tryParse(string s)
{
try
{
auto dt = parseDT(s);
stderr.writefln!"valid '%s': %s"(s, dt);
}
catch (Exception e)
stderr.writefln!"INVALID '%s': %s"(s, e.msg);
}
void main()
{
auto vs = [
"",
"1",
"1/1",
"1/1/1",
"1/1/1 1",
"1/1/1 1:1",
"1/1/1 1:1:1",
];
vs.each!tryParse;
}
```
outputs:
```
INVALID '': 0 is not a valid month of the year.
INVALID '1': parseToFormatSpec: Cannot find character '/' in the
input string.
INVALID '1/1': parseToFormatSpec: Cannot find character '/' in
the input string.
valid '1/1/1': 0001-Jan-01 00:00:00 <<< see here
INVALID '1/1/1 1': parseToFormatSpec: Cannot find character ':'
in the input string.
INVALID '1/1/1 1:1': parseToFormatSpec: Cannot find character ':'
in the input string.
valid '1/1/1 1:1:1': 0001-Jan-01 01:01:01
```
Is space a special char for `formattedRead` and it simple stop
parse without throwing exception if not found space (that
represented in fmt string)?
Have `formattedRead` any other special chars?
Or it's bug?
Re: Weird interaction with public and non-public imports
On Thursday, 28 January 2021 at 13:13:46 UTC, Paul Backus wrote: ... https://issues.dlang.org/show_bug.cgi?id=21589 These issues are always so subtle and specific yet so annoying, e.g.: https://issues.dlang.org/show_bug.cgi?id=21496 and https://issues.dlang.org/show_bug.cgi?id=21377
Re: Weird interaction with public and non-public imports
On Thursday, 28 January 2021 at 13:07:13 UTC, SealabJaster wrote: Please see: https://run.dlang.io/is/2mwcPH I'd expect that the `isInstanceOf` would be true instead of false here. Commenting out the public import changes the output of `fullyQualifiedName`. I can kind of see why this happens, but it's kind of annoying when things like `isInstanceOf` silently fail due to this. Looks like a bug to me. I recommend filing a bug report on issues.dlang.org.
Weird interaction with public and non-public imports
Please see: https://run.dlang.io/is/2mwcPH I'd expect that the `isInstanceOf` would be true instead of false here. Commenting out the public import changes the output of `fullyQualifiedName`. I can kind of see why this happens, but it's kind of annoying when things like `isInstanceOf` silently fail due to this. For context: I found this after getting a compiler error after stitching a bunch of D files together, which is why there's a mix of a public import and local import in the same file. Part of me feels like it's a bug since if the alias `T` is using one "version" (for lack of a better word) of `Nullable`, then surely that same "version" would be given to `isInstanceOf`? It can get a bit more interesting as well: https://run.dlang.io/is/n5jzJs
[Issue 17436] Weird `cast(double) i != cast(double) i` on 32-bit hosts
https://issues.dlang.org/show_bug.cgi?id=17436 --- Comment #3 from kinke --- Ah sorry, that's for signed long only. --
[Issue 17436] Weird `cast(double) i != cast(double) i` on 32-bit hosts
https://issues.dlang.org/show_bug.cgi?id=17436 --- Comment #2 from kinke --- [The generated code uses the ucomisd instruction, which is SSE2, so using cvtsi2sd (SSE2) and avoiding the x87 should be feasible.] --
[Issue 17436] Weird `cast(double) i != cast(double) i` on 32-bit hosts
https://issues.dlang.org/show_bug.cgi?id=17436 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Walter Bright --- What's happening here is the conversion of ulong.max to double is done by the x87. The computed value is cached in the x87, rather than rounded to double, and reused. Hence, it is different than when stored to an intermediary double and reloaded. This does not occur on 64 bit targets because those do the calculation in 64 bit XMM registers, not the 80 bit x87 registers. The compiler could force a round-to-64 after all operations by writing to memory and then reloading it, but this would be execrably and unacceptably slow. When you need and can afford the load/store, use: https://dlang.org/phobos/core_math.html#.toPrec wontfix --
[Issue 17436] Weird `cast(double) i != cast(double) i` on 32-bit hosts
https://issues.dlang.org/show_bug.cgi?id=17436 Walter Bright changed: What|Removed |Added Keywords||backend CC||bugzi...@digitalmars.com --
[Issue 21123] ICE during toChars() of weird CommaExp lowering
https://issues.dlang.org/show_bug.cgi?id=21123 kinke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from kinke --- *** This issue has been marked as a duplicate of issue 21092 *** --
[Issue 21123] ICE during toChars() of weird CommaExp lowering
https://issues.dlang.org/show_bug.cgi?id=21123 --- Comment #3 from kinke --- (In reply to kinke from comment #2) > Seems to be fixed indeed according to run.dlang.io. Well I've assumed the nightly build there was up-to-date, but it's some old v2.091 build (as is the Windows nightly download). - Anyway, build it myself, and yes, fixed in master but not in stable. --
[Issue 21123] ICE during toChars() of weird CommaExp lowering
https://issues.dlang.org/show_bug.cgi?id=21123 --- Comment #2 from kinke --- Seems to be fixed indeed according to run.dlang.io. I'd like to see this in the v2.093.1 point release though, as it would e.g. seriously impede LDC debugging (-vv output etc.) for upcoming v1.23. --
[Issue 21123] ICE during toChars() of weird CommaExp lowering
https://issues.dlang.org/show_bug.cgi?id=21123 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- I think that this issue is fixed in the latest master. I cannot reproduce it. Can you please check if you can reproduce with git head and close this if it was fixed? --
[Issue 21123] ICE during toChars() of weird CommaExp lowering
https://issues.dlang.org/show_bug.cgi?id=21123 Walter Bright changed: What|Removed |Added Keywords||ice-on-valid-code CC||bugzi...@digitalmars.com --
[Issue 21123] New: ICE during toChars() of weird CommaExp lowering
https://issues.dlang.org/show_bug.cgi?id=21123
Issue ID: 21123
Summary: ICE during toChars() of weird CommaExp lowering
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ki...@gmx.net
The following code hits an assertion in the frontend (and makes it crash with
disabled assertions), presumably since v2.093 (as LDC v1.22 works), when
compiling with `-vcg-ast` (in order to call toChars()):
-
struct Foo
{
static Foo make() { return Foo(); }
size_t length() { return 0; }
}
void main()
{
auto x = Foo.make().make().length;
}
-
The lowering for main is already weird with v2.092:
ulong x = (make() , make)().length();
--
[Issue 18831] Weird interaction between std.variant, std.algorithm.iteration.map, and alias this
https://issues.dlang.org/show_bug.cgi?id=18831 Paul Backus changed: What|Removed |Added Status|NEW |RESOLVED CC||snarwin+bugzi...@gmail.com Resolution|--- |FIXED --- Comment #2 from Paul Backus --- The given example compiles successfully as of DMD 2.092.1. --
Re: Weird behavior with UDAs
On Saturday, 13 June 2020 at 13:08:29 UTC, realhet wrote: How can be a string represented with 'null' by default instead on `""`. Unless I state it explicitly with name="" ? o.O Because string is simply `alias string = immutable(char)[]`, and default initializer for arrays is null.
Re: Weird behavior with UDAs
On Saturday, 13 June 2020 at 12:55:36 UTC, realhet wrote:
Hello, I have a problem I can't even understand with the code
For the first I realized that an UDA can be a type too, and come
up with this:
template getUDA(alias a, U){
enum u = q{ getUDAs!(a, U)[$-1] };
static if(hasUDA!(a, U) && !is(mixin(u)))
enum getUDA = mixin(u);
else
enum getUDA = U.init;
}
So I always get an instance of the UDA with the default values.
But the second question is still beyond me:
How can be a string represented with 'null' by default instead on
`""`. Unless I state it explicitly with name="" ? o.O
Re: Weird behavior with UDAs
On Saturday, 13 June 2020 at 12:55:36 UTC, realhet wrote:
My first question is, how to avoid that error with A.i4? Why
is there a difference between @UNIFORM and @UNIFORM(), do the
first returns a type and the later returns a value?
Basically yeah. a UDA in D is just whatever you write gets
directly attached - it does no additional processing. So if you
give it a type, it keeps a type. If a value, it keeps the value.
The simplest answer is probably "don't do that"; if it is meant
to be a value, always give it a value.
But you could also write your own get UDA thing that recognizes
the type (the check: static if(is(attribute)) for a type vs
static if(is(typeof(attribute))) for the value) and returns the
init value if you want in your code.
My second quertion is, why the UNIFORM struct with
uninitialized string producing UNIFORM(null).
How can be a difference when I say name="", and it's just the
same as the default string initializer, and then it produce
UNIFORM("")?
null and "" can be used interchangeably and sometimes yield the
same thing, but they aren't exactly the same.
Since you specified it there in the definition as a default value
in a struct the compiler used that distinction. I'd suggest you
write what you mean even in cases where it is the same so you
cover the bases.
If you specifically want null, check `str is null` and use ` =
null`. If either is fine, just use `str.length == 0`.
Weird behavior with UDAs
Hello, I have a problem I can't even understand with the code
below:
https://run.dlang.io/is/7yXAEA
import std.stdio, std.range, std.algorithm, std.traits, std.meta;
struct UNIFORM{ string name; }
struct A{
int i1;
@UNIFORM() int i2;
@UNIFORM("fuzz") int i3;
@UNIFORM int i4;
}
template getUDA(alias a, U){
static if(hasUDA!(a, U)) enum getUDA = getUDAs!(a, U)[$-1];
else enum getUDA = U.init;
}
pragma(msg, getUDA!(A.i1, UNIFORM)); //UNIFORM(null)
pragma(msg, getUDA!(A.i2, UNIFORM)); //UNIFORM(null)
pragma(msg, getUDA!(A.i3, UNIFORM)); //UNIFORM("fuzz");
pragma(msg, getUDA!(A.i4, UNIFORM)); //Error: initializer must be
an expression, not UNIFORM
struct UNIFORM2{ string name=""; }
struct B{ @UNIFORM2() int i1; }
pragma(msg, getUDA!(B.i1, UNIFORM2)); //UNIFORM("") instead if
UNIFORM(null)
//
My first question is, how to avoid that error with A.i4? Why is
there a difference between @UNIFORM and @UNIFORM(), do the first
returns a type and the later returns a value?
My second quertion is, why the UNIFORM struct with uninitialized
string producing UNIFORM(null).
How can be a difference when I say name="", and it's just the
same as the default string initializer, and then it produce
UNIFORM("")?
Thank You!
[Issue 10110] Weird linker crashing
https://issues.dlang.org/show_bug.cgi?id=10110 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from Mathias LANG --- According to Kenji's comment, this works now. I suppose this was left open because of D1. Closing as "WORKSFORME". If it is not fixed and you still reproduce the error, please open a new issue on Optlink's Github: https://github.com/DigitalMars/optlink/issues --
[Issue 6318] module isn't fully processed under weird conditions
https://issues.dlang.org/show_bug.cgi?id=6318 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --
[Issue 18303] Unqual gives weird results for const types
https://issues.dlang.org/show_bug.cgi?id=18303 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --
[Issue 15028] Weird disassembly on asm.dlang.org
https://issues.dlang.org/show_bug.cgi?id=15028 berni44 changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@d-ecke.de Resolution|--- |INVALID --- Comment #1 from berni44 --- asm.d-lang.org seems not to exist anymore... --
