[Issue 15417] Wrong parameter passing for variadic nested functions within aggregate

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15417

--- Comment #4 from Iain Buclaw  ---
(In reply to Walter Bright from comment #3)
> _argptr and _arguments are there for "D style variadics". core.stdc.stdarg
> is for "C style variadics". I.e. using va_arg for C-style will not work.

I beg your pardon?

The _argptr variable is computed from va_start, so is perfectly valid for use
in va_arg.  See for example, std.format.doFormat!()

--

[Issue 15417] Wrong parameter passing for variadic nested functions within aggregate

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15417

--- Comment #5 from Iain Buclaw  ---
(In reply to Mathias Lang from comment #2)
> assert(char.init == va_arg!(char)(arglist));

Is it the same if you do.

 char buf;
 va_arg(ap, arglist[0], );
 assert(char.init == buf);

--

[Issue 15478] New: Constant folding inconsistency

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15478

  Issue ID: 15478
   Summary: Constant folding inconsistency
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thomas.bock...@gmail.com

struct Foo(N)
{
this(N value) { }
auto bug() { return 0; }
}

void main()
{
enum Foo!int foo = 0;
Foo!int[foo.bug] bar; // Error: integer constant expression expected
instead of Foo().bug

enum foo_bug = foo.bug;
Foo!int[foo_bug] baz; // OK
}

The declarations of `baz` and `bar` should be semantically equivalent, but
apparently something went wrong with `bar`.

(This was reduced from a much larger program which triggered the problem
seemingly at random. very annoying.)

--

[Issue 15479] COFF: phobos/win64.mak failed to make clean with MODEL=32mscoff

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15479

j...@red.email.ne.jp changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from j...@red.email.ne.jp ---
https://github.com/D-Programming-Language/phobos/pull/3885

--

[Issue 14506] Wrong floating point type inferred for function with auto return type

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14506

--- Comment #1 from monkeywork...@hotmail.com ---
With version 2.069.1 of DMD my case now passes, but Ali's remains the same.

--

[Issue 15479] New: COFF: phobos/win64.mak failed to make clean with MODEL=32mscoff

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15479

  Issue ID: 15479
   Summary: COFF: phobos/win64.mak failed to make clean with
MODEL=32mscoff
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

I wonder if COFF support on Win32 is official or not.

cd src\phobos
make -f win64.mak clean MODEL=32mscoff

This doesn't work.

The cause is etc.c.zlib has its own makefile but the tweak with
"MODEL=32mscoff" misses.

I will send a PR.

--

[Issue 15478] Constant folding inconsistency

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15478

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||ag0ae...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from ag0ae...@gmail.com ---
Looks like dmd doesn't realize that it's a function call between the brackets.
Adding empty parentheses is a workaround.

Here's a slightly smaller test case that shows a different error, but I suspect
the same root cause:

int bug() { return 0; }
void main()
{
int[bug()] bar1; /* works */
int[bug] bar2; /* Error: index is not a type or an expression */
}


--

[Issue 14804] Comparing two Nullables does not check if either is null

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14804

--- Comment #2 from monkeywork...@hotmail.com ---
I agree opCmp is a little weird to implement for Nullable, but it's really not
much different from NaN. If we follow what the floating point numbers do:

Nullable!int n1;
Nullable!int n2 = 0;

assert(!(n1 < n2) && !(n1 == n2) && !(n1 > n2));

Of course the semantics of NaN are somewhat confusing at first and possibly
bug-prone, so it may not be something we want to duplicate in another type if
possible. Interestingly, this is how the built-in "nullable" types behave when
compared:

Object o1 = null;
Object o2 = new Object();
assert(o1 > o2); //Segfault

int* i1 = null;
int* i2 = new int(0);
assert(i1 <= i2); //One of these will pass
assert(i1 > i2);

int[] a1 = null;
int[] a2 = [0];
assert(a1 <= a2); //I didn't know this was valid code;
assert(a1 > a2);  //it must compare the array pointers
  //and thus work similarly to case 2

So it looks like we have our choice of semantics to choose from.


Either way, the issue of opCmp is completely separate from opEquals, so I don't
agree that this bug should be closed. Every built-in nullable type in D works
as I described, and I don't believe that Nullable should be any different.

Object o1 = null;
Object o2 = new Object();
assert(o1 != o2); //Passes

int* i1 = null;
int* i2 = new int(0);
assert(i1 != i2); //Passes

int[] a1 = null;
int[] a2 = [0];
assert(a1 != a2); //Passes


The fact that these issues pop up when you actually try to use Nullable in any
serious way suggest to me that its design is deeply flawed, and that it should
be deprecated and replaced at some point. However, until that happens, we
should aim to improve it as much as possible without breaking existing code.

If you don't want to open a defect for Nullable.opCmp, that's fine with me, but
let's not close this one for opEquals.

--

[Issue 10765] Cannot Use Index in Foreach When Iteratee is a Tuple

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10765

monkeywork...@hotmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--