[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

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

Boris Carvajal  changed:

   What|Removed |Added

 CC||boris...@gmail.com

--


[Issue 13983] RefCounted needs to be @safe

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13983

Ate Eskola  changed:

   What|Removed |Added

 CC||ajiesk...@gmail.com
Summary|RefCounted needs to be  |RefCounted needs to be
   |pure, @safe, nothrow|@safe

--- Comment #8 from Ate Eskola  ---
Regarding nothrow and pure, this is fixed as Phobos unittests confirm. Changing
the title. And by the way, the struct is also @nogc and -betterC.

@safe remains a problem though. It cannot be added in vanilla D, but with
-dip1000 flag there may be hope. Atila recently made a PR that attempts to do
just that: https://github.com/dlang/phobos/pull/8101

--


[Issue 22241] New: Compiler fails to match a more specialized overload

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22241

  Issue ID: 22241
   Summary: Compiler fails to match a more specialized overload
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid, spec
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: maxsamu...@gmail.com

In the following, the specialized parameter (int a) takes over the general one
(T a) as expected:

int foo()(int a)
{
return 1;
}

int foo(T)(T a)
{
return 2;
}

void main()
{
int x;
assert(foo(x) == 1); // ok
assert(foo("a") == 2); // ok
}


But, if another general parameter is added, the "matches both" error occurs:

int foo(T)(T t, int a)
{
return 1;
}

int foo(T, U)(T t, U a)
{
return 2;
}

void main()
{
int x;
assert(foo(0, x) == 1);
assert(foo(0, "a") == 2);
}

onlineapp.d(14): Error: `onlineapp.foo` called with argument types `(int, int)`
matches both...

Both should be either rejected or accepted.

--


[Issue 5305] Cannot take pointer to intrinsic function

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5305

--- Comment #10 from Dlang Bot  ---
dlang/phobos pull request #8210 "std.math: Reference Issue 5305 in unittest
taking pointer to function" was merged into master:

- 5a39765c4c5e4c34cd5ee84bae0901af6869d66f by Iain Buclaw:
  std.math: Reference Issue 5305 in unittest taking pointer to function

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

--


[Issue 22215] returning expired stack pointers in @system code allowed by spec, not by implementation

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22215

--- Comment #3 from Dennis  ---
(In reply to Ate Eskola from comment #2)
> There appears to be two bugs, one in vanilla DMD and one with -dip1000.

That's right, the latter one is https://issues.dlang.org/show_bug.cgi?id=19873

--


[Issue 22215] returning expired stack pointers in @system code allowed by spec, not by implementation

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22215

--- Comment #2 from Ate Eskola  ---
There appears to be two bugs, one in vanilla DMD and one with -dip1000.

As Dennis said, my initial example fails to compile regardless of the compiler
switches used. But there is a watered-down version of my workaround:

```d
int* f()
{ int x = 42;
  auto wannaBePointer = &x;
  return wannaBePointer;
}
```

This one compiles with vanilla DMD, but the -dip1000 bug prevents compiling it
with the said flag.

The full workaround in the initial example still compiles with the flag too.

--


[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

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

Paul Backus  changed:

   What|Removed |Added

 CC||snarwin+bugzi...@gmail.com

--- Comment #23 from Paul Backus  ---
> At the very least, 1 -> true should match as an implicit conversion, not an 
> exact match (in which case, one gets an overload resolution error rather than 
> a bug).

In this example, both `1 -> long` and `1 -> bool` are implicit conversions, so
partial ordering is used, and `1 -> bool` is correctly selected as the
more-specialized implicit conversion.

The only thing one can really object to here is that the `1 -> bool` conversion
is allowed in the first place. But since DIP 1015 has been rejected, it seems
like that objection has been overruled, so there is (unfortunately) nothing
left to be done here.

--


[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

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

--- Comment #22 from deadalnix  ---
At the very least, 1 -> true should match as an implicit conversion, not an
exact match (in which case, one gets an overload resolution error rather than a
bug).

That would still be bad, but that would at least not be the opposite one what
anyone sensible expects.

--


[Issue 18161] std.algorithm.iteration.chunkBy should be usable in @safe

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18161

--- Comment #2 from Dlang Bot  ---
@dukc created dlang/phobos pull request #8213 "Partially solve issue 18161 -
splitWhen and most of chunkBy now @safe" mentioning this issue:

- Partially solve issue 18161. splitWhen and chunkBy when using forward ranges
is now safe

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

--


[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

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

deadalnix  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #21 from deadalnix  ---
I'm reopening this.

Sorry, but to put it bluntly, this behavior is completely retarded. There is no
nicer way to put it.

This is turning writing a piece of code I'm working on into a total nightmare
as integers keeps being converted to bool in weird edge cases.

--


[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

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

Paul Backus  changed:

   What|Removed |Added

 CC||deadal...@gmail.com

--- Comment #20 from Paul Backus  ---
*** Issue 22240 has been marked as a duplicate of this issue. ***

--


[Issue 22240] Erroneous overload selection bool vs long

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22240

Paul Backus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||snarwin+bugzi...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Paul Backus  ---


*** This issue has been marked as a duplicate of issue  ***

--


[Issue 22240] New: Erroneous overload selection bool vs long

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22240

  Issue ID: 22240
   Summary: Erroneous overload selection bool vs long
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: deadal...@gmail.com

import std.stdio;

void foo(bool b) {
writeln("This is bool!");
}

void foo(long l) {
writeln("This is bool!");
}

As expected by nobody, foo(0) and foo(1) actually call foo(bool). Every other
integer value or a non constant integer value ends up calling foo(long).

I assume that VRP detects that 0 and 1 can be coerced into bools, but even in
this case, this should error with an error mentionning that overload
resolutionf ailed as there are two candidates.

There are 0 circumstance where the VRP call should be preferred to the non VRP
one.

--


[Issue 5305] Cannot take pointer to intrinsic function

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5305

--- Comment #9 from Dlang Bot  ---
dlang/dmd pull request #13016 "test: Remove test case for issue 5305" was
merged into master:

- 499d0aa53ac2b4d6a3c39dd7976432de4f926538 by Iain Buclaw:
  test: Remove test case for issue 5305

  This test is already covered in Phobos std.math

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

--


[Issue 19842] std.signals Segfault could take other delegates than member function pointers

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19842

Ate Eskola  changed:

   What|Removed |Added

Summary|std.signals Segfault when   |std.signals Segfault could
   |connecting with a lambda|take other delegates than
   ||member function pointers
   Severity|critical|enhancement

--- Comment #8 from Ate Eskola  ---
The documetation is now clarified, but it still would be a nice plus for the
slot to accept any delegate of the correct type. I changed the severity to
enhancement.

--


[Issue 19320] -cov and -O yield variable used before set

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19320

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Dlang Bot  ---
@RazvanN7 created dlang/dmd pull request #13015 "Fix Issue 19320 - -cov and -O
yield variable used before set" fixing this issue:

- Fix Issue 19320 - -cov and -O yield variable used before set

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

--


[Issue 22239] New: Can't migrate from postblits if they are used without frame pointer

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=22239

  Issue ID: 22239
   Summary: Can't migrate from postblits if they are used without
frame pointer
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ajiesk...@gmail.com

So, postblits are considered a legacy construct that should be migrated to copy
constructors. However, there is an instance where that cannot be done:

---
struct PostBlitted(alias al){
  this(this){}
  void x(){} //a member function so that an instance contains a frame pointer
}

struct CopyConstructed(alias al){
  this(ref typeof(this)){};
  void x(){} //a member function so that an instance contains a frame pointer
}

void main(){
  PostBlitted!(x => x) a;
  CopyConstructed!(x => x) b;

  a.f; //compiles
  b.f; //does not
}

void f(T)(T x){
  T y = x;
}
---

There should be a way to define a copy constructor so that it works even when
the caller does not have a frame pointer for the new struct instance.

--


[Issue 8671] Segmentation fault with 1.0 - uniform(0.0, 1.0)

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8671

--- Comment #9 from Dlang Bot  ---
dlang/dmd pull request #13013 "test: Remove test case for issue 8671" was
merged into master:

- 5674c4fa3e8c70320c0f636c46660de49f61e86f by Iain Buclaw:
  test: Remove test case for issue 8671

  This has been moved to std.random in Phobos

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

--


[Issue 8671] Segmentation fault with 1.0 - uniform(0.0, 1.0)

2021-08-25 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8671

--- Comment #8 from Dlang Bot  ---
dlang/phobos pull request #8209 "std.random: Add test for Issue 8671" was
merged into master:

- d5676dd5343ee33fd81348713f03a082643a414e by Iain Buclaw:
  std.random: Add test for Issue 8671

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

--