[Issue 16063] DLL projects seem to ignore DllMain, won't link

[via Digitalmars-d-bugs]

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

--- Comment #1 from Manu  ---
Seems that it expects '/DLL' given to the linker, but it's not.
I added -L/DLL to additional options and it links.

This should probably be there automatically.

--

[Issue 16063] New: DLL projects seem to ignore DllMain, won't link

[via Digitalmars-d-bugs]

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

  Issue ID: 16063
   Summary: DLL projects seem to ignore DllMain, won't link
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

I create a DLL project: Properties -> General -> Output Type = DLL, Subsystem =
Windows

I get the error when linking:
  error LNK2019: unresolved external symbol WinMain referenced in function "int
__cdecl invoke_main(void)" (?invoke_main@@YAHXZ)

Seems to want WinMain, even though it's a DLL.
If I change 'Subsystem' to 'Not Set', it complains that main() is missing
instead.

--

[Issue 16062] New: Add 'clear' method to OutBuffer (std.outbuffer)

[via Digitalmars-d-bugs]

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

  Issue ID: 16062
   Summary: Add 'clear' method to OutBuffer (std.outbuffer)
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jrdemail2000-dl...@yahoo.com

Enhancement request: Add an API to OutBuffer (std.outbuffer) to clear the data
in an OutBuffer. The intent is to reuse the OutBuffer, but without reallocating
the memory for the internally managed buffer. This would be similar to
std.array.appender.clear method.

It appear that this could be done by setting the 'offset' member of the
OutBuffer to zero. If this works correctly, a clear API could be exposed that
implements this.

A forum thread on this topic:
https://forum.dlang.org/thread/bbjgfradpwqaelaru...@forum.dlang.org

--

[Issue 16061] New: 2.071.1-b1 regression -- Works with 2.071

[via Digitalmars-d-bugs]

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

  Issue ID: 16061
   Summary: 2.071.1-b1 regression -- Works with 2.071
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: pun...@coverify.org

$ dmd -c foo.d

Fails with 2.071.1-b1 with error:
bar.d(3): Error: T.Zoo is not a template, it is a overloadset
bar.d(8): Error: template instance bar.Boo!(Foo) error instantiating
foo.d(3): Error: mixin foo.Foo.Bar!() error instantiating


// file foo.d
class Foo {
  import bar;
  mixin Bar;
}

// file bar.d
class Zoo(V) {}
template Boo(T) {
  alias Boo = T.Zoo!T;
}
mixin template Bar() {
  class Zoo(V) {}
  alias U = typeof(this);
  alias BooThis = Boo!U;
}

--

[Issue 16060] New: extern(C++) abstract base class and interface

[via Digitalmars-d-bugs]

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

  Issue ID: 16060
   Summary: extern(C++) abstract base class and interface
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

In this case, we have an example of single-inheritance in C++, but D treats
this construct as multiple-inheritance, and the struct's don't match.


C++:


#include 

class I
{
public:
  virtual void f1() = 0;
  virtual float f2() = 0;
};

class Test : public I
{
public:
  int t;

  Test(int t) : t(t) {}
};

class Blah : public Test
{
public:
  Blah() : Test(0xbaadf00d) {}

  void f1() {}
  float f2() { return 10.f; }
};

extern "C" {
  I* test()
  {
return new Blah;
  }

  Test* test2()
  {
return new Blah;
  }
}



D:
--

import std.stdio;

extern (C++) interface I
{
  void f1();
  float f2();
}

extern (C++) abstract class Test : I
{
  int t;
}

extern (C) I test();
extern (C) Test test2();

int main(string[] argv)
{
  auto i = test();
  i.f1();

  auto j = test2();
  float f = j.f2(); // CRASH! looks up vtable address: [i + 8], expect: vtable
at [i]

  writeln("Hello D-World! ", f);
  return 0;
}

--

[Issue 16059] New: needed better error messages for failed overloads

[via Digitalmars-d-bugs]

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

  Issue ID: 16059
   Summary: needed better error messages for failed overloads
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: poliklosio.dl...@gmail.com

I think I may have an idea for a usable solution to improve error messages.

Example of an error I got from dmd:

C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(298,24): Error: template
std.conv.toImpl cannot deduce function from argument types
!(ubyte[])(RangeT!(Array!ubyte)), candidates are:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(364,3):   
std.conv.toImpl(T, S)(S value) if (isImplicitlyConvertible!(S, T) &&
!isEnumStrToStr!(S, T) && !isNullToStr!(S, T))
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(478,3):   
std.conv.toImpl(T, S)(ref S s) if (isRawStaticArray!S)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(494,3):   
std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) &&
is(typeof(S.init.opCast!T()) : T) && !isExactSomeString!T &&
!is(typeof(T(value
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(545,3):   
std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(T ==
struct) && is(typeof(T(value
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(594,3):   
std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(T ==
class) && is(typeof(new T(value
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(298,24):... (9 more,
-v to show) ...
src\app.d(36,36): Error: template instance
std.conv.to!(ubyte[]).to!(RangeT!(Array!ubyte)) error instantiating
dmd failed with exit code 1.


There are multiple problems with this error message:
- The information that the source of the problem was the call to a "to"
function is not at the top.
- It is missing some very important information, in particular the general idea
of what types are accepted by the "to" function. It only shows the way the
constrains are *implemented*, it doesn't tell directly what the author wanted
to achieve. When one writes 20 overloads, its usually because there is some
commmon property among the accepted types which cannot be easily expressed with
the type system.
- It doesn't show any useful speculation as to what mith be the cause of the
error in this particular use case.


There was a forum thread started by Andrei about other improvements to messages
already:
http://forum.dlang.org/post/nfllhq$19tk$1...@digitalmars.com
but it was focused on generating better messages from the constraints
themselves, which is, IMHO, an inferior solution if not a lost cause.

I would like to propose another solution which may improve experience
regardless of the number of overloads, architecture of constrains and all the
other technical issues, by laveraging the expressive power of English language.

If the library writer could write something like this (example for the
std.conv.to case):

pragma(on_overload_resolution_error, "toImpl", "
You used the \"to\" function incorrectly which failed at the point of toImpl
template instantiation.
The \"to\" function is meant for simple convertions which typically preserve
the converted value, for example from double -> int, or double[] -> int[].
Typical mistakes when calling the \"to\" function involve: Calling on range
types rather than arrays...
")

This tells the compiler to display the "You used the ..." message at the top of
the appropriate error message, in case there is an overload resolution error
when using the toImpl function.

--

[Issue 16029] D exception aborts program when called from C++

[via Digitalmars-d-bugs]

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #1 from Adam D. Ruppe  ---
This actually works for me.. what are some other details of your setup?

--

[Issue 15547] 64-bit struct alignment in core.sys.windows.setupapi inconsistent with msvc

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||j...@red.email.ne.jp

--- Comment #1 from j...@red.email.ne.jp ---
We can get a work around with string mixin( though a bit ugly hack).

See my PR for issue 16049.
https://github.com/dlang/druntime/pull/1576
(including "Add AlignedStr helper and fix setupapi" )

Otherwise, an old enhancement request of issue 9766 could resolve this simply.

--

[Issue 16026] std.math.frexp!float() wrong for very small subnormal values

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a6a1957be301860b1fa5d9205f1edd7a39cc0a1a
Fix issue 16026: std.math.frexp!float() wrong for very small subnormal values

https://github.com/dlang/phobos/commit/4991b82304b421f56e5394ba849826ee3251c89f
Merge pull request #4337 from tsbockman/issue_16026

Fix issue 16026: std.math.frexp!float() wrong for very small subnormals

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/f0f38381ed27fd8a4d2e36d13623698970cff7bd
Revert "[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates
are ignored"

https://github.com/dlang/dmd/commit/64f3fdb27b6d9d465c307b45c26a6c9fe10844b8
Merge pull request #5800 from dlang/revert-5724-fix-15925-stable

Revert "[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates
are ignored"

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
 Resolution|FIXED   |INVALID

--- Comment #5 from Walter Bright  ---
This is not a bug, the behavior is on purpose and as designed. This was
discussed at length for an analogous case, imports in base classes.

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to revert-5724-fix-15925-stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/f0f38381ed27fd8a4d2e36d13623698970cff7bd
Revert "[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates
are ignored"

--

[Issue 16049] core.sys.windows structs have wrong sizes and aligns

[via Digitalmars-d-bugs]

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

--- Comment #3 from j...@red.email.ne.jp ---
(In reply to jiki from comment #2)
> Note that I deferred to commit a module MMSYSTEM 
> because it gets many conflicts with/without my previous commit #1574 for
> issue 15959.

Fixed.

--

[Issue 16056] immutable delegate can mutate through context pointer

[via Digitalmars-d-bugs]

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

--- Comment #5 from ag0ae...@gmail.com ---
(In reply to Eyal Lotem from comment #4)
> immutable void delegate() pure
> 
> vs.
> 
> immutable void delegate() immutable pure

When the delegate is part of an immutable struct instance, it has the former
type, too:


struct S { void delegate() pure f; }
immutable s = S();
pragma(msg, typeof(s.f)); /* immutable(void delegate() pure) */


I suppose your point is that it should be the latter type, with two
"immutable"s.

Fair enough, but I don't think that distinction is worth having. D doesn't have
head const with pointers. Why should we make delegates a special case?

So in my opinion, `immutable void delegate()` should imply an immutable context
pointer, making it the same type as `immutable void delegate() immutable`. Just
like `immutable(int*)` is the same as `immutable(immutable(int)*)`.

The compiler agrees (to some extent):


alias A = immutable int* delegate();
alias B = immutable int* delegate() immutable;
static assert(is(A == B)); /* passes */


But then there's this:


void main()
{
int x = 1;
const void delegate() dg1 = { ++x; };
const void delegate() const dg2 = { ++x; };
}


That compiles, but when you take the dg1 line away, then the dg2 line isn't
accepted anymore. And when you swap them around, both lines are rejected.
There's obviously something wrong here. I've filed a separate issue:
https://issues.dlang.org/show_bug.cgi?id=16058

--

[Issue 16058] New: `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently

[via Digitalmars-d-bugs]

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

  Issue ID: 16058
   Summary: `immutable delegate()` and `immutable delegate()
immutable` are considered equal but treated
differently
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: accepts-invalid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Spin-off from issue 16056.

dmd considers the two types to be equal:


alias A = immutable int* delegate();
alias B = immutable int* delegate() immutable;
static assert(is(A == B)); /* passes */


That's ok. But it treats them differently.

This is accepted with `-version=V1`, but it's rejected with `-version=V2`:


version (V1) alias T = immutable void delegate();
version (V2) alias T = immutable void delegate() immutable;

void main()
{
int x = 1;
T dg = { ++x; };
}


Both V1 and V2 should be rejected.

Furthermore, when you use both types, the first one determines how the second
is treated.

This is accepted:


void main()
{
int x = 1;
immutable void delegate() dg1 = { ++x; };
immutable void delegate() immutable dg2 = { ++x; };
}


Swap the two delegates lines and both are rejected. Again, both variants should
be rejected.

All this applies to const as well, of course.

--

[Issue 16056] immutable delegate can mutate through context pointer

[via Digitalmars-d-bugs]

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

--- Comment #4 from Eyal Lotem  ---
immutable void delegate() pure(In reply to ag0aep6g from comment #3)
> (In reply to Eyal Lotem from comment #2)
> > This is simpler -- but this simpler example isn't a bug: a pure func that
> > takes a mutable delegate is "weakly pure" because it doesn't take an
> > immutable argument. You could say that the simplified pure func takes an
> > explicitly mutable argument, so it is known to be weakly pure.
> 
> pure_func's parameter isn't mutable. It's explicitly marked immutable.

immutable void delegate() pure

vs.

immutable void delegate() immutable pure

Arguably, you can claim that if you've chosen the former form, you knowingly
forfeited mutability for the delegate.

However, once the delegate is wrapped in a struct, you would expect that
transitivity would take care of full immutability.

--

[Issue 15959] core.sys.windows modules should be modified for x64

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/caf04060ca300ac0ca68e68e9b8de6fecec281cc
Merge pull request #1574 from qchikara/additional-15959

Fix issue 15959 additional fixes

--

[Issue 16056] immutable delegate can mutate through context pointer

[via Digitalmars-d-bugs]

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

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to Eyal Lotem from comment #2)
> This is simpler -- but this simpler example isn't a bug: a pure func that
> takes a mutable delegate is "weakly pure" because it doesn't take an
> immutable argument. You could say that the simplified pure func takes an
> explicitly mutable argument, so it is known to be weakly pure.

pure_func's parameter isn't mutable. It's explicitly marked immutable.

--

[Issue 16056] immutable delegate can mutate through context pointer

[via Digitalmars-d-bugs]

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

--- Comment #2 from Eyal Lotem  ---
(In reply to ag0aep6g from comment #1)
> The struct doesn't really matter here, as far as I see. Simplified code:
> 
> 
> import std.stdio;
> 
> pure void pure_func(immutable void delegate() pure f)
> {
> f();
> }
> 
> void main() {
> int y;
> writeln("Before: ", y);
> pure_func({ y++; });
> writeln("After: ", y);
> }
> 
> 
> Possibly a duplicate of issue 11043 or issue 1983.

This is simpler -- but this simpler example isn't a bug: a pure func that takes
a mutable delegate is "weakly pure" because it doesn't take an immutable
argument. You could say that the simplified pure func takes an explicitly
mutable argument, so it is known to be weakly pure.

When you do take an immutable argument in a pure function -- the immutability
is supposed to be transitive -- so it is supposed to be strongly pure.

--

[Issue 16057] [TDPL] synchronized (a, b) compiles and runs with wrong semantics

[via Digitalmars-d-bugs]

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

--- Comment #1 from Andrei Alexandrescu  ---
Test code (thanks Steve Schveighoffer) should not print "oops!" but does:


import std.concurrency;
import core.sync.mutex;
import core.thread;
import std.stdio;

__gshared Mutex a;
__gshared Mutex b;

shared static this()
{
a = new Mutex;
b = new Mutex;
}

void badThread()
{
synchronized(a)
{
writeln("a is locked!");
while(1) { Thread.sleep(1.seconds); }
}
}

void main()
{
spawn();
Thread.sleep(1.seconds);
synchronized(a, b)
{
writeln("oops!");
}
}

--

[Issue 16057] New: [TDPL] synchronized (a, b) compiles and runs with wrong semantics

[via Digitalmars-d-bugs]

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

  Issue ID: 16057
   Summary: [TDPL] synchronized (a, b) compiles and runs with
wrong semantics
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

According to TDPL, multiple-arguments synchronized locks them in increasing
address order so as to prevent deadlock. What the statement actually does is...
use the comma expression for the arguments, so only the last object gets
locked.

--

[Issue 12389] Operating system C functions should be marked as 'nothrow'

[via Digitalmars-d-bugs]

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

--- Comment #1 from q...@web.de ---
Resolved as of https://github.com/dlang/druntime/commit/3c9aee8fcb1d9 ?

--

[Issue 16056] immutable delegate can mutate through context pointer

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||ag0ae...@gmail.com
  Component|dlang.org   |dmd
Summary|[The D Bug Tracker] |immutable delegate can
   ||mutate through context
   ||pointer
   Severity|enhancement |normal

--- Comment #1 from ag0ae...@gmail.com ---
The struct doesn't really matter here, as far as I see. Simplified code:


import std.stdio;

pure void pure_func(immutable void delegate() pure f)
{
f();
}

void main() {
int y;
writeln("Before: ", y);
pure_func({ y++; });
writeln("After: ", y);
}


Possibly a duplicate of issue 11043 or issue 1983.

--

[Issue 16056] New: [The D Bug Tracker]

[via Digitalmars-d-bugs]

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

  Issue ID: 16056
   Summary: [The D Bug Tracker]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: eyal.lo...@gmail.com

The "immutable" qualifier is not transitive, as it claims to be.

import std.stdio;

struct Foo {
int y;
void delegate() pure f;
}

pure void pure_func(immutable Foo foo)
{
foo.f();
}

void main() {
int y;
immutable x = Foo(1, { y++; });
writeln("Before: ", y);
pure_func(x);
writeln("After: ", y);
}

Prints out:
Before: 0
After: 1

A pure function with only immutable parameters should have no possible
side-effects. However, due to 'immutable' not transitively applying to
delegates' context:

A) We can have a mutable-context delegate inside an immutable struct
B) A pure function taking exclusively immutable parameters is not really pure

The fix would be to transitively apply the "immutable" qualifier to the context
type of the Foo.f delegate.

--