[Issue 17363] @safety hole due to $ caching in slice expressions

[via Digitalmars-d-bugs]

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

--- Comment #2 from ki...@gmx.net ---
> The slice should be loaded before evaluation of slice arguments, then length
> is safe to cache, see issue 17364.

Your argument for loading & caching length and pointer before evaluating the
bounds expressions being?
I mean it's perfectly safe and IMHO less awkward the other way around, loading
the current length for each $ and loading the base pointer after evaluating the
bounds expressions, with full side effects visibility for lvalue slicees.
People do come up with (arguably bad) code where this matters:
https://github.com/ldc-developers/ldc/issues/1433

--

[Issue 17361] latest windows 10 insider preview and dmd no longer runs.

[via Digitalmars-d-bugs]

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

--- Comment #3 from steven kladitis  ---
1703, build 16184.101.
I sent Microsoft a note asking to figure it out.

--

[Issue 17366] Inferrence results in a missing error for final

[via Digitalmars-d-bugs]

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

--- Comment #3 from Adam D. Ruppe  ---
My guess is that func.d's findVtblIndex function fails to find the base class
method because `type.equals` and `type.covariant` fail to take into account
inference.

Looking at mtype.d, there is 

  if (!t1n || !t2n) // happens with return type inference
goto Lnotcovariant;

Which I'm guessing isn't right, it should actually analyze the body and fill
those types in.

--

[Issue 17366] Inferrence results in a missing error for final

[via Digitalmars-d-bugs]

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #2 from Adam D. Ruppe  ---
No, it isn't a template. Try putting `import external.module;` inside. If it is
a template, there's no "cannot find module" error unless you actually call it
(lazy local imports), but for a function, the error does exist.

final foo() { import...} DOES produce the error. Ditto for `auto ref`
parameters, they aren't allowed here either.

--

[Issue 17367] New: CodeView/MSCOFF: bad debug information for enumerators

[via Digitalmars-d-bugs]

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

  Issue ID: 17367
   Summary: CodeView/MSCOFF: bad debug information for enumerators
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Keywords: symdeb
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

Compile:

module test;
enum E
{
one,
two
}

with "dmd -m64 -g -c test.d"

and analyze it with cvdump from
https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump:

...
*** TYPES

0x1000 : Length = 22, Leaf = 0x1507 LF_ENUM
# members = 2,  type = T_INT4(0074) field list type 0x1001
enum name = test.E

0x1001 : Length = 22, Leaf = 0x1203 LF_FIELDLIST
list[0] = LF_ENUMERATE, none, value = 0, name = 'one'
Error : Leaf is not aligned on a 4 byte boundary
list[1] = LF_ENUMERATE, none, value = 1, name = 'two'

0x1002 : Length = 42, Leaf = 0x1504 LF_CLASS
# members = 0,  field list type 0x, FORWARD REF,
Derivation list type 0x, VT shape type 0x
Size = 0, class name = object.TypeInfo_Enum


Note the reported misalignment which can cause debuggers to get really
confused.

--

[Issue 17364] Difference between slicing a slice and a reference to a slice

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17363

--

[Issue 17363] @safety hole due to $ caching in slice expressions

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17364

--- Comment #1 from anonymous4  ---
The slice should be loaded before evaluation of slice arguments, then length is
safe to cache, see issue 17364.

--

[Issue 17364] Difference between slicing a slice and a reference to a slice

[via Digitalmars-d-bugs]

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

--- Comment #3 from anonymous4  ---
(In reply to kinke from comment #2)
> but *when* the loads happen is clearly crucial

That's the loading I talk about.

--

[Issue 17366] Inferrence results in a missing error for final

[via Digitalmars-d-bugs]

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

Daniel Kozak  changed:

   What|Removed |Added

 CC||kozz...@gmail.com

--- Comment #1 from Daniel Kozak  ---
final print() { writeln(this); }

is a template!!!. So I believe this is the main source of this "bug".

When you add void it makes print normal member function.

final print() { writeln(this); }
is not same as
final void print() { writeln(this); }

It is more like

final void print()() { writeln(this); }

--

[Issue 17366] New: Inferrence results in a missing error for final

[via Digitalmars-d-bugs]

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

  Issue ID: 17366
   Summary: Inferrence results in a missing error for final
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: issues.dl...@jmdavisprog.com

This code

import std.stdio;

class A
{
final print() { writeln(this); } // no return type
}

class B : A
{
final void print() { writeln(this); }
}

void main()
{
auto b = new B;
b.print();

A a1 = b;
a1.print();

A a2 = new A;
a2.print();
}

compiles and runs, giving

q.B
q.B
q.A

as output. Putting

pragma(msg, typeof(print));

after the declartion for A.print results in compilation printing

@system void()
q.d(11): Error: function q.B.print cannot override final function q.A.print

whereas putting the same pragma after B.print results in

void()

If A.print is changed to have void, then you get the error and the type that's
printed is the same as B.print.

I find it odd that @system void() and void() would any different, since the
default is @system - so that may or may not be a bug - but it's definitely a
bug that there isn't a compilation error in all cases, since A.print is final
and returns the same type as B.print (whether inferrence is involved or not).
The fact that whether the pragma is there or not affects whether you get a
compilation error is particularly disturbing, but it's a bug regardless.

--

[Issue 17366] Inferrence results in a missing error for final

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--