[Issue 17327] New: std.getopt: repeated options unrecognised

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17327

  Issue ID: 17327
   Summary: std.getopt: repeated options unrecognised
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: novalazy+dl...@gmail.com

getopt reports that a valid option is unrecognised if it is used multiple
times. e.g.

getopt(args, "dry-run|n", );

An exception is throw for both "prog -n -n" and "prog --dry-run -n".

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

Walter Bright  changed:

   What|Removed |Added

   Keywords||dll

--

[Issue 17099] c:\d\dmd2\samples\d needs to be updated to compile with latest versions like 2073...

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17099

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Hardware|x86_64  |All
 Resolution|--- |FIXED
 OS|Windows |All

--- Comment #7 from Walter Bright  ---
All merged.

--

[Issue 6527] Ambiguous mangling of inout parameters

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=6527

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r.sagita...@gmx.de
 Resolution|--- |WONTFIX

--- Comment #1 from Rainer Schuetze  ---
Two character manglings are common by now and no single character encodigs
left, so the demangler should be able to look-ahead by the additional character
(and mostly does).

--

[Issue 1550] D DLLs close standard input/output streams when unloading

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=1550

Rainer Schuetze  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #5 from Rainer Schuetze  ---
Still happens with the example dclient/dserver in dmd/samples.

--

[Issue 17310] [SPEC] Ambiguous mangling for 'Y', Objective-C function or variadic arguments?

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17310

--- Comment #1 from Rainer Schuetze  ---
> Granted, the function type might never appear without a pointer prefix in the 
> argument list

It appears inside QualifiedName for nested symbols inside an extern(Objective-C
) function.

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

Walter Bright  changed:

   What|Removed |Added

Summary|2.072 gc changes totally|2.072 gc changes broke 32
   |broke 32 bit Windows DLLs   |bit Windows DLLs

--

[Issue 17326] 2.072 gc changes totally broke 32 bit Windows DLLs

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #1 from Walter Bright  ---
The PR that broke it all:

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

--

[Issue 17326] New: 2.072 gc changes totally broke 32 bit Windows DLLs

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

  Issue ID: 17326
   Summary: 2.072 gc changes totally broke 32 bit Windows DLLs
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

How it is supposed to work is that if a program dynamically loads a DLL, then
they need to share the same GC instance. This is done by the DLL, when it
loads, calling gc_setProxy(the main program's gc instance pointer).

The DLL links in gcstub/gc.d, which contained a Proxy struct with a bunch of
fields that are pointers to functions. The equivalent is gc/gc.d.

Unfortunately, 2.072 totally revamped everything about this in gc/*, but failed
to update gcstub/gc. So now gcstub.gc_setProxy() gets sent a pointer to a
completely different interface, causing it to crash when used.

This is a disastrous bug, as it makes using D DLLs completely unusable in
Win32, and is likely the source of the common complaint that Windows DLLs do
not work.

--

[Issue 15536] [std.experimental.logger] More detailed example

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15536

--- Comment #2 from Bastiaan Veelo  ---
It has been a while, and I cannot reproduce the link- and runtime errors.
However, things still don't work as expected.

>From what I read from https://dlang.org/phobos/std_experimental_logger.html,
"User Defined Logger", I should be able to remove the time stamp etc. by doing
this:

```
import std.experimental.logger;

/**
Overrides FileLogger to remove the time stamp.
*/
class AnonimousFileLogger : FileLogger
{
this(in string fn) @safe
{
super(fn);
}

   /* This method SHOULD override the base class method.
*/
override protected void writeLogMsg(ref LogEntry payload)
{
//this.beginLogMsg(payload.file, payload.line, payload.funcName,
//payload.prettyFuncName, payload.moduleName, payload.logLevel,
//payload.threadId, payload.timestamp, payload.logger);
this.logMsgPart(payload.msg);
this.finishLogMsg();
}

}

void main()
{
auto logger = new AnonimousFileLogger("log.txt");
logger.trace("I'm here.");
}
```

I'd expect `log.txt` to just contain "I'm here.", instead it contains
"2017-04-14T11:54:00.405:app.d:main:38 I'm here.".

Surely there is an explanation for this, but it is not obvious to me and I'd
like an example in the docs for how to do this properly.

I've managed to get what I want with the following, overriding `beginLogMsg`
with an empty implementation, but it feels wrong and there should be a better
way:

```
import std.experimental.logger;

/**
Overrides FileLogger to remove the time stamp.
*/
class AnonimousFileLogger : FileLogger
{
this(in string fn) @safe
{
super(fn);
}
import std.concurrency : Tid;
import std.datetime : SysTime;
override protected void beginLogMsg(string file, int line, string funcName,
string prettyFuncName, string moduleName, LogLevel logLevel,
Tid threadId, SysTime timestamp, Logger logger)
@safe
{
}
}

void main()
{
auto logger = new AnonimousFileLogger("log.txt");
logger.trace("I'm here.");
}
```

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #9 from Iain Buclaw  ---
(In reply to Rainer Schuetze from comment #8)
> > Any other of the TemplateArg prefixes 'S' (TypeStruct), 'H' 
> > (TypeAssocArray) and 'T' (TypeTypedef) should be affected aswell.
> 
> Probably not, as the rule above avoids trouble with symbol aliases, and
> types only contain QualifiedName which only contain function types.

Yeah, I think I would have spotted it otherwise.

I think all I can do on my side is have a boolean function that attempts to
parse TypeFunctionNoReturn and returns true only if a digit immediately follows
(have matched the next QualifiedName in the grammar rule).

It means in the worst case I'm going over the section of the symbol twice, but
at least I don't have a special case for Pascal.  :-(

--