[Issue 22500] ImportC: Lots of errors when compiling tomlc99

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22500

moonlightsenti...@disroot.org changed:

   What|Removed |Added

 CC||moonlightsentinel@disroot.o
   ||rg
Summary|ImportC: Lots of errors |ImportC: Lots of errors
   ||when compiling tomlc99

--


[Issue 22500] New: ImportC: Lots of errors

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22500

  Issue ID: 22500
   Summary: ImportC: Lots of errors
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: rem...@tutanota.com

I'm trying to compile the [toml99](https://github.com/cktan/tomlc99) C library
using ImportC but I'm getting some errors. I have already created a thread in
the forums and I was told to come here to submit an issue. In the link bellow
you can see the problem I'm having so you can also follow the discussion and
have more info and also so I don't retype all that stuff. Link:

https://forum.dlang.org/thread/mbwwrtmiairzhdzli...@forum.dlang.org

--


[Issue 22210] std.meta.allSatisfy in mutual recursion classes cannot be compiled

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22210

--- Comment #2 from Dlang Bot  ---
@tom-tan created dlang/druntime pull request #3618 "Fix issue 22210 - Revert
#3459 and #3463" mentioning this issue:

- Add test for issue 22210

https://github.com/dlang/druntime/pull/3618

--


[Issue 22499] New: Copy construction of nested struct rejected

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22499

  Issue ID: 22499
   Summary: Copy construction of nested struct rejected
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD 2.098.0:

---
auto makeFoo(){
struct Foo{
this(ref typeof(this)){}
}
return Foo();
}

void main(){
auto foo=makeFoo();
auto bar=foo; // error
}
---

Yields:

---
Error: cannot access frame pointer of `tt.makeFoo.Foo`
---

This makes no sense, as there is a frame pointer in foo that can just be copied
over to bar before calling the copy constructor. core.lifetime.copyEmplace
actually handles this case correctly.

--


[Issue 22498] auto ref function with auto ref parameter causes noncopyable payload be cleaned twice

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22498

Tomáš Chaloupka  changed:

   What|Removed |Added

   Severity|critical|normal

--- Comment #1 from Tomáš Chaloupka  ---
I've found possible workaround.

```
auto ref unwrap(EX)(auto ref EX res) {
static if (__traits(isRef, res)) {
printf("unwrap(ref)\n");
return res.get();
} else {
printf("unwrap(val)\n");
auto ret = res.get().move(); // < NRVO
return ret;
}
}
```

Then with `Foo f = gen(42).unwrap;`

It otputs:
```
~this(0)
~this(0)
~this(0)
unwrap(val)
~this(0)
~this(42)
```

But I'm still puzzled about what's wrong with the original one.

--


[Issue 22498] New: auto ref function with auto ref parameter causes noncopyable payload be cleaned twice

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22498

  Issue ID: 22498
   Summary: auto ref function with auto ref parameter causes
noncopyable payload be cleaned twice
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: chalu...@gmail.com

With a code like

```
import core.lifetime : forward;
import core.stdc.stdio;
import std.algorithm : move;

struct Value(T) {
private T storage;

this()(auto ref T val) {
storage = forward!val;
}

ref inout(T) get() inout {
return storage;
}
}

Value!T value(T)(auto ref T val) {
return Value!T(forward!val);
}

auto ref unwrap(EX)(auto ref EX res) {
printf("unwrap()\n");
return res.get();
}

struct Foo {
int n;
@disable this(this);
~this() { printf("~this(%d)\n", n); }
}

auto gen() {
Foo f;
f.n = 42;
return value(f.move());
}

void main() {
Foo f;
f = gen().unwrap.move;
}
```

`unwrap` accepts copy of non copyable `Value!Foo` that results in this output:

```
~this(0)
~this(0)
~this(0)
unwrap()
~this(42) <- this is a copy (that shouldn't exist) being destroyed
~this(0)
~this(42)
```

But it should't compile as output from `gen()` is rvalue.
`__traits(isRef, res)` yields false in `unwrap` as expected, same with
`isCopyable!(Value!Foo)`.

Or is NRVO working even when return value is passed as a value to the `unwrap`?
But then why wouldn't unwrap.move() cause the payload to be reset?
And is it ok to ref being returned from `unwrap` when it's from local value
parameter?

--


[Issue 22497] New: Spurious dual-context error

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22497

  Issue ID: 22497
   Summary: Spurious dual-context error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Consider:

template canon(string v) {
auto fun(alias lambda)(int x) {
return lambda(x);
}
}

alias f1 = canon!"abc".fun;

void main() {
int x = 42;
f1!(y => y + x)(1);
}

The code produces the error:

Deprecation: function `onlineapp.main.f1!((y) => y + x).fun` function requires
a dual-context, which is deprecated

There is no dual context anywhere in sight. The canon template takes a
compile-time string, which requires no context.

This blocks phobos versioning.

--


[Issue 20204] need to fix ABI about registers using

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20204

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@ljmf00 created dlang/dlang.org pull request #3120 "spec: abi: clarify calling
convention for other architectures other t…" fixing this issue:

- spec: abi: clarify calling convention for other architectures other than x86

  Observing the assembly generated by the following source file in either DMD
and
  LDC:

  ```d
  extern (C) void ccall( size_t a, size_t b, size_t c );
  extern (D) void dcall( size_t a, size_t b, size_t c );

  //...

  ccall( a, b, c ); // RDI, RSI, RDX
  dcall( a, b, c ); // RDX, RSI, RDI
  ```

  The parameters are passed in the reverse order in functions with `extern(D)`
  linkage. Furthermore, on x86 the calling convention seems to be what is
  described by the current subsections, not only matching Windows x86, but also
  appears to be the same behaviour on System V ABI.

  Fixes #20204 .

  Signed-off-by: Luís Ferreira 

https://github.com/dlang/dlang.org/pull/3120

--


[Issue 22496] importC: Error: illegal combination of type specifiers

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22496

--- Comment #5 from bachm...@yahoo.com ---
I attached a file that compiles with dmd. I had to comment out anything with:

-  `__extension__`
- Restricted pointers `*__restrict`
- `_Float128`
- `__asm__`

And in the source, anything with ISNAN, or in the preprocessed file,

- `__builtin_isnan`

--


[Issue 22496] importC: Error: illegal combination of type specifiers

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22496

bachm...@yahoo.com changed:

   What|Removed |Added

   Attachment #1834|0   |1
is obsolete||

--- Comment #4 from bachm...@yahoo.com ---
Created attachment 1835
  --> https://issues.dlang.org/attachment.cgi?id=1835=edit
Commented file that compiles

--


[Issue 15939] GC.collect causes deadlock in multi-threaded environment

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15939

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #28 from Dlang Bot  ---
@hatf0 updated dlang/druntime pull request #3617 "Move SIGUSR1/SIGUSR2 to SIGRT
for GC" fixing this issue:

- Fix Issue 15939 -- Move SIGUSR1/SIGUSR2 to SIGRT for GC

https://github.com/dlang/druntime/pull/3617

--


[Issue 22496] importC: Error: illegal combination of type specifiers

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22496

--- Comment #3 from bachm...@yahoo.com ---
Most of the remaining errors are due to dmd choking on restricted pointers.
Anything with char *__restrict causes an error.

--


[Issue 22496] importC: Error: illegal combination of type specifiers

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22496

--- Comment #2 from bachm...@yahoo.com ---
If I comment out all single lines that are just

__extension__

as in the second uploaded file, that error goes away. Now I get

dmd -c fsign_d2.c

/usr/include/string.h(43): Error: found `__dest` when expecting `,`
/usr/include/string.h(43): Error: found `__src` when expecting `,`
/usr/include/string.h(54): Error: found `__dest` when expecting `,`
/usr/include/string.h(54): Error: found `__src` when expecting `,`
/usr/include/string.h(122): Error: found `__dest` when expecting `,`
/usr/include/string.h(122): Error: found `__src` when expecting `,`
/usr/include/string.h(125): Error: found `__dest` when expecting `,`
/usr/include/string.h(126): Error: found `__src` when expecting `,`
/usr/include/string.h(130): Error: found `__dest` when expecting `,`
/usr/include/string.h(130): Error: found `__src` when expecting `,`
/usr/include/string.h(133): Error: found `__dest` when expecting `,`
/usr/include/string.h(133): Error: found `__src` when expecting `,`
/usr/include/string.h(147): Error: found `__dest` when expecting `,`
/usr/include/string.h(148): Error: found `__src` when expecting `,`
/usr/include/string.h(336): Error: found `__s` when expecting `,`
/usr/include/string.h(336): Error: found `__delim` when expecting `,`
/usr/include/string.h(341): Error: found `__s` when expecting `,`
/usr/include/string.h(342): Error: found `__delim` when expecting `,`
/usr/include/string.h(343): Error: found `__save_ptr` when expecting `,`
/usr/include/string.h(346): Error: found `__s` when expecting `,`

--


[Issue 22496] importC: Error: illegal combination of type specifiers

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22496

--- Comment #1 from bachm...@yahoo.com ---
Created attachment 1834
  --> https://issues.dlang.org/attachment.cgi?id=1834=edit
Source file without that error

--


[Issue 22496] New: importC: Error: illegal combination of type specifiers

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22496

  Issue ID: 22496
   Summary: importC: Error: illegal combination of type specifiers
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bachm...@yahoo.com

Created attachment 1833
  --> https://issues.dlang.org/attachment.cgi?id=1833=edit
Source file I'm trying to compile

I ran the original source file through the gcc preprocessor and got the
attached fsign_d.c file. It compiles with gcc:

gcc -c fsign_d.c

but when using dmd:

dmd -c fsign_d.c


/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(322): Error: illegal combination
of type specifiers
/usr/include/string.h(43): Error: found `__dest` when expecting `,`
/usr/include/string.h(43): Error: found `__src` when expecting `,`

--


[Issue 15889] Array bounds check should report index and length

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15889

Dennis  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dennis  ---
Now merged to stable. If you need better error messages for out of bounds slice
copy, please open a new enhancement request.

--


[Issue 22468] DWARF: dchar type is missing encoding

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22468

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/dmd pull request #13254 "backend: dwarfdbginf: add UTF encoding to dchar
types" was merged into master:

- a7195f830c89cd1b844a80b9905fa8f79e179287 by Luís Ferreira:
  backend: dwarfdbginf: add UTF encoding to dchar types

  Currently `dchar` types are exported as signed encoding which is wrong,
because
  `dchar` is supposed to represent UTF-32 encoded characters, so we should
export
  the right encoding to the debug info.

  Fixes #22468 .

  Signed-off-by: Luís Ferreira 

https://github.com/dlang/dmd/pull/13254

--


[Issue 22221] [dip1000] pure function can escape parameters through Exception

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=1

Atila Neves  changed:

   What|Removed |Added

 CC||atila.ne...@gmail.com
   Severity|normal  |major

--


[Issue 22488] data should work with const/immutable Array's

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22488

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #8313 "Merge `stable` in `mater`" was merged into
master:

- a22571f59a9fdf06738bea56bac54799a6b7bc3b by MoonlightSentinel:
  Fix 22488 - Add inout to allow Array.data for const/immutable Array's

  Simply propagate the const'ness to the return slice.

https://github.com/dlang/phobos/pull/8313

--


[Issue 22458] OpenBSD: Add OpenBSD to std/system.d OS list

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22458

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #8313 "Merge `stable` in `mater`" was merged into
master:

- 8e9e9b6a348bdff07c8a389dcade7d239194f676 by Brian Callahan:
  Fix Issue 22458 - OpenBSD: Add OpenBSD to std/system.d OS list

https://github.com/dlang/phobos/pull/8313

--


[Issue 22416] Unify polyImpl implementations

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22416

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #8313 "Merge `stable` in `mater`" was merged into
master:

- 8a42656f67286e47c8f9dce2252b617408cf7d1f by Brian Callahan:
  Fix Issue 22416 - Unify polyImpl implementations

https://github.com/dlang/phobos/pull/8313

--


[Issue 22487] Array!T.init.data crashes

2021-11-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22487

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #8313 "Merge `stable` in `mater`" was merged into
master:

- c0981769a06bd3a011fd4760d88a39b590659685 by MoonlightSentinel:
  Fix 22487 - Don't access payload for unititialized array data

  Explicitly return `[]` when `store` wasn't intialized yet.

https://github.com/dlang/phobos/pull/8313

--