[Issue 7535] Position of method in code inside class/struct decides that code is proper or invalid

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #2 from Vladimir Panteleev  ---
I'm pretty sure this is not reasonably possible to make work.

The expression  is ambiguous, as it can refer to either the
static or non-static method. Now, the D compiler has some internal capabilities
of working with overload sets. However, in this case, this ambiguous expression
is passed as a template value parameter to opOpAssign. Because it is passed as
a regular parameter (and not e.g. alias), then it must have a type, so the
compiler is forced to pick one overload at this point (assuming this didn't
happen earlier, for the & operator). Only when the append occurs inside the
opOpAssign implementation can the overload set be reasonably resolved to the
one or other overload; however, at that point, the opOpAssign method had
already been instantiated with a concrete type, so it is too late to do
anything.

So, for this to work, the compiler would need to speculatively instantiate the
function with the type of each overload in the overload set, which would almost
surely be prohibitively complicated and expensive.

The other option would be to prefer non-static overloads when a class instance
(not just type) is supplied before the dot, however I believe that the overload
resolution rules are currently complicated enough to warrant this arguably
strange and easily avoidable use case.

I'll leave this open because picking an overload by a "whichever comes first"
rule is problematic - probably neither of the presented test cases should
compile.

--

[Issue 13836] DMD linker (v2.066) not working with older "ld"

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
Generally, the solution to situations where you are forced to use unusually old
software is to use similarly old software. Old releases of D are available at
http://downloads.dlang.org/releases/2.x/.

As this bug was filed over 2 years ago, I'm going to close it; please reopen if
you think this issue is still relevant today.

--

[Issue 17022] brew install dmd has a bug in its creation of dmd.conf

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
Err, I'm not sure who maintains the brew recipe for dmd, but I don't think it's
anyone from the core team, so I think this bug was filed in the wrong place.

--

[Issue 14404] ClassInfo.create should forbid creating nested classes

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P1  |P3
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
Summary|Class nested within |ClassInfo.create should
   |function cannot be created  |forbid creating nested
   ||classes
 OS|Linux   |All
   Severity|critical|minor

--

[Issue 14404] ClassInfo.create should forbid creating nested classes

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Kenji Hara from comment #1)
> Are you requiring the create() call should throw a runtime exception for the
> impossible nested class construction?

Updated issue title accordingly.

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #18 from Vladimir Panteleev  ---
Satoshi, please file extant cases as new issues and close this one. Multiple
bugs filed under one issue make it difficult to track which ones are still
unfixed, and which one any particular pull request fixes.

--

[Issue 14176] the code has a link problem.

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #6 from Vladimir Panteleev  ---
Closing as per Kenji's explanation.

--

[Issue 16972] Issue diagnostic for throwing from a scope(exit) block

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
Good find. A pertinent post from that thread:

http://forum.dlang.org/post/1237688782434087169.692302seewebsiteforemail-erdan@news.digitalmars.com

Indeed, it seems facetious to "forbid" throw but allow calling non-nothrow
functions, and enforcing the latter is likely to break too much code now.

So, we need confirmation that the current compiler implementation is sane and
deals with throws properly, after which the spec could be updated.

--

[Issue 16972] Issue diagnostic for throwing from a scope(exit) block

[via Digitalmars-d-bugs]

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

--- Comment #2 from Ali Cehreli  ---
To complete, the spec says "A scope(exit) or scope(success) statement may not
exit with a throw, goto, break, continue, or return; nor may it be entered with
a goto."

And I found a very long forum thread:

  http://forum.dlang.org/post/m0l0p4$28la$1...@digitalmars.com

--

[Issue 12374] undefined reference to ...__initZ link error

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
Unfortunately the test case you provided is not complete because it is not
self-contained. The makefile references files in ~/.dub, and attempting to
build the makefile fails due to those files not being found. Anyone can only
guess what exact versions need to be there, and the exact versions are
necessary to ensure that the issue is reproduced in the same way as you are
encountering it.

Since there was no activity on this issue for over 3 years, I am going to close
it, but please reopen it if you can provide a working, self-contained test
case.

--

[Issue 7856] static import-ed module behaves as symbol it contents

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #1 from Vladimir Panteleev  ---
With the provided example, all I get is:

modmain.d(7): Error: no type for typeid(mod)

even with the DMD versions released at the time this bug was filed.

Please reopen if you can provide a working example.

--

[Issue 16972] Issue diagnostic for throwing from a scope(exit) block

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 16972] Issue diagnostic for throwing from a scope(exit) block

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
Is it the compiler or the spec that's wrong? In a trivial test, throwing in a
scope(exit) seems to work as expected, and if an exception is already in
flight, the new one appears to be correctly chained.

--

[Issue 16373] gcc 6.1.1 compatibility

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #2 from Vladimir Panteleev  ---
I can build dmd fine today with gcc (GCC) 6.3.1 20170306, so I assume this has
since been fixed.

--

[Issue 12205] Tools build process cannot find druntime and phobos

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #5 from Vladimir Panteleev  ---
Closing per merged pull comment above.

--

[Issue 17438] std.conv.parse documentation contradiction

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Brad Roberts from comment #2)
> The entire family
> is documented as not throwing.

Where does it say that?

I think you're misinterpreting what "It does not throw if it could not convert
the entire input" means. It does not mean "it does not throw, period". It also
doesn't mean "It does not throw if it could not convert any part of the input".
What it means is that if it finds a valid value at the start of the input,
which it consumes and returns, it leaves the rest of the input in place, which
is useful when you need to parse as much of a string (or character range) up
until a non-specific separator or character not representing the value.

--

[Issue 17554] New: non-blocking connect doesn't work for TcpSocket on win

[via Digitalmars-d-bugs]

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

  Issue ID: 17554
   Summary: non-blocking connect doesn't work for TcpSocket on win
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

auto s = new TcpSocket;
s.blocking = false;
s.connect(addr); 

ubyte[1234] tmp;
auto len = s.receive(arr);

assert(len != Socket.ERROR || wouldHaveBlocked, s.getErrorText);

fails with "the operation was completed successfully"

and passes on linux

--

[Issue 15482] new uuid.d forbids to link statically with other libraries

[via Digitalmars-d-bugs]

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

--- Comment #7 from Temtaime  ---
Yes, do it

--

[Issue 17438] std.conv.parse documentation contradiction

[via Digitalmars-d-bugs]

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

Brad Roberts  changed:

   What|Removed |Added

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

--- Comment #2 from Brad Roberts  ---
Re-read the description of the parse family of functions I cut and pasted into
the bug report (which is still what the page says).  The entire family is
documented as not throwing.  One function does, and that it documents at the
specific site of that variant doesn't give it license to violate the spec at
the higher level.  One of them is still wrong, and it's that it throws.

--

[Issue 17551] VC build: bad mangling of real template argument

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/6b0a15db30b37fc4556b65a18abf2fbd3c562f70
fix issue 17551 - VC build: bad mangling of real template argument

fix ld_sprint not reflecting case of format character

https://github.com/dlang/dmd/commit/16f4f4b9dcc5d585085944c2fdbc0a42c362e5d1
Merge pull request #6936 from rainers/issue17551

fix issue 17551 - VC build: bad mangling of real template argument

--

[Issue 10393] demangle doesn't work for unicode symbol names

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Schuetze  ---
seems correct to me too. With OMF there is an issue when symbols are
compressed, because these interfere with UTF8, but that's not a problem of the
demangler.

--

[Issue 10189] demangle doesn't work with __ModuleInfoZ __initZ __arrayZ

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
These symbols are demangled for some time now:
https://github.com/dlang/druntime/commit/83053e8fb5bd733a09442d1ed318efef15ed3b1b

--

[Issue 17553] New: std.json invalid utf8 sequence

[via Digitalmars-d-bugs]

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

  Issue ID: 17553
   Summary: std.json invalid utf8 sequence
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

It is possible to read a file into a string. JSONValue happily accepts this
string which contains binary data.
But the moment you want to get data using js.toString an exception is thrown:
core.exception.UnicodeException@src\rt\util\utf.d(292): invalid UTF-8 sequence



import std.json;
import std.file: read;

void main()
{
string s = cast(string) read(`C:\D\dmd2\windows\bin\dmd.exe`);
JSONValue js = JSONValue(s);

string s2 = js.toString; // this line will throw the exception
}

--

[Issue 6525] Numeric literals should always be mangled with a leading 'i'

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #1 from Rainer Schuetze  ---
This has been committed 3 years ago:
https://github.com/dlang/dmd/commit/24ae9f83b94227f758ae5b367b355ab309421e72

--

[Issue 17552] New: Cannot implicitly convert expression (struct this)

[via Digitalmars-d-bugs]

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

  Issue ID: 17552
   Summary: Cannot implicitly convert expression (struct this)
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

I created a custom type which enables me to have enums which have as their
initial state, the init value of their base type. Something similiar to
Nullable...

enum Reason : string {CO = "Co", FU = "Fu", CA = "Ca"}
struct TestStruct {InitialEnum!Reason reason;}

This line raises the error:
TestStruct s2 = TestStruct(Reason.FU);
>> Error: cannot implicitly convert expression ("Fu") of type Reason to 
>> InitialEnum!(Reason)

While this line is working fine:
TestStruct s1 = {reason: Reason.FU};

I asked this question in the learning forum and got the advice to create an
issue.

struct InitialEnum(T)
{
import std.traits: OriginalType, EnumMembers;
import std.conv: to;

private T _value;
private bool _isEmpty = true;
alias EnumBaseType = OriginalType!T;

@property EnumBaseType baseTypeValue() { return (_isEmpty) ?
EnumBaseType.init : _value; }
@property T value(){ return _value; }
@property bool isEmpty() { return _isEmpty;}

alias baseTypeValue this;

void opAssign(EnumBaseType value)
{
if (value == EnumBaseType.init)
{
_isEmpty = true;
return;
}

foreach (member; EnumMembers!T)
{
if (value == member)
{
_value = member;
_isEmpty = false;
return;
}
}
throw new Exception("Value "~value.to!string~" is not a valid enum
value");
}

this(T t)
{
_isEmpty = false;
_value = t;
}

this(EnumBaseType value)
{
opAssign(value);
}
}

--

[Issue 17548] [REG2.072.0] Forward reference error with scope function parameters

[via Digitalmars-d-bugs]

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

--- Comment #4 from Elie Morisse  ---
https://github.com/dlang/dmd/pull/6937/

--

[Issue 9182] [REG2.059] Forward reference error with static immutable struct members

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|Forward reference error |[REG2.059] Forward
   |with static immutable   |reference error with static
   |struct members  |immutable struct members

--- Comment #3 from Vladimir Panteleev  ---
Introduced in
https://github.com/dlang/dmd/commit/92c8e7bdcc9ad100f8efca5cac1095ff255413d3

--

[Issue 13633] __fieldPostBlit generates even if this(this) anntotated with @disable

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
This was fixed in https://github.com/dlang/dmd/pull/4073.

--

[Issue 9550] Repeat!fun(size_t n)

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #4 from Vladimir Panteleev  ---
(In reply to daniel from comment #0)
> The use case is where you want to repeat an (impure) function n times lazily.

This doesn't make sense to me. Laziness and impurity do not mix.

> iota(100).map!(x => uniform(0, 76));

This code is conceptually wrong. By itself, this code does nothing. Advancing
the range will do nothing. Advancing the range while evaluating .front will do
something; but so will accessing .front in a loop without advancing the range.
The resulting range object is broken by design in several aspects.

It seems to me that you are trying to shoehorn an operation into a design which
was not really meant for it. In the case of random numbers, the proper solution
would be a PRNG range, which has correctly-implemented .front (which always
returns the same value while not advancing), .popFront (which advances the
PRNG), and .save (which makes a copy of the PRNG's state).

I'll close this as the last activity on this bug was over 4 years ago. If you
think you have a valid use case, feel free to reopen, though I would suggest
creating a forum thread about this first instead.

--

[Issue 5904] std.json parseString doesn't handle chars outside the BMP

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
Test case:

/ test.d /
import std.json;

void main()
{
string s = `"\uD834\uDD1E"`;
auto j = parseJSON(s);
assert(j.str == "\U0001D11E");
}
//

--

[Issue 16436] Implement pragma(switches, "")

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #7 from Vladimir Panteleev  ---
Giving the source code control over compiler behaviour is not desirable for the
same reason why letting programs know (at compile time) which switches are
active isn't. Many guarantees will no longer hold and debugging things reliably
becomes more difficult in general.

Furthermore, a pragma is not a good place for this. Pragmas participate in
semantics and can be emitted by CTFE.

Furthermore, compiler switches are heavily specific to the implementation. GDC
and LDC each use different sets of switches - their compatibility layer with
DMD switches comes as a stand-alone program.

Finally, this is a non-trivial change. The correct avenue for such a proposal
would be a DIP.

--

[Issue 11473] rdmd --exclude=module1.package

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
Then there would be no way to distinguish excluding just the package.d module
vs. the entire package.

Exclusions work by looking at dmd's -v output (import lines, specifically).
Since rdmd isn't really aware of how module names are resolved to file names,
it probably can't reliably add the implicit .package suffix.

Anyway, I don't think this is a problem on its own; we can just say that rdmd
is interpreting module names as they appear in the module statement, and not
the import statement. I'll close this for now, but if you have a use case for
the proposed behaviour, feel free to reopen.

--

[Issue 17548] [REG2.072.0] Forward reference error with scope function parameters

[via Digitalmars-d-bugs]

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

--- Comment #3 from johanenge...@weka.io ---
Extra testcase by Elie, modifying fwdref2.d to:
```
struct S2 {
// void bar(int arg = .fwdref1.cnst) {}
S1 s;
import fwdref2;
}
```

--

[Issue 17551] VC build: bad mangling of real template argument

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull
   Severity|enhancement |normal

--- Comment #1 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/6936

--

[Issue 15459] [REG2.065.0] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|stdin.byLine.each!(map!some |[REG2.065.0]
   |func) compiles, fails to|stdin.byLine.each!(map!some
   |link with ld|func) compiles, fails to
   ||link with ld
   Severity|major   |regression

--- Comment #10 from Vladimir Panteleev  ---
Regression (changing the compilation error into a link error + possible
accepts-invalid) introduced in https://github.com/dlang/dmd/pull/2851

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

--- Comment #9 from Vladimir Panteleev  ---
(In reply to ag0aep6g from comment #8)
> So the invalid front is supposed to be accepted (if it's never called)? Then
> I suppose the accepts-invalid aspect of this issue is WONTFIX.

Forward references and generally order of semantic analysis is a tricky subject
and I'm not qualified to answer with authority whether the behaviour here can
actually be called a bug or not, however I do know that we generally want the
compiler to be as lazy as possible/reasonable for performance reasons. For
example, currently unit tests are not even parsed without unittest, so you can
put any series of tokens in an unittest block as long as the curly braces are
balanced. So, even if there is a bug here, fixing it would not align with
long-term goals.

> But it should link then, no?

Oh right, I missed that the test case you posted also exhibits the link
failure.

--

[Issue 17551] New: VC build: bad mangling of real template argument

[via Digitalmars-d-bugs]

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

  Issue ID: 17551
   Summary: VC build: bad mangling of real template argument
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

When building dmd with the VC runtime, templates with real arguments are
mangled wrong:

module test;
real foo(real x)() { return x; }

pragma(msg, (foo!0.3).mangleof); //
_D4test__T3fooVeex13334pN2ZQBdFNaNbNiNfZe


Please note the additional 'x' before the constant as well as the small 'p'
before the exponent (sould be 'P')

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

--- Comment #8 from ag0ae...@gmail.com ---
(In reply to Vladimir Panteleev from comment #7)
> This is not a valid reduction because .front is never called.

front is never called in the original code either.

> The compiler
> seems to be skipping semantic analysis of uncalled functions here to avoid
> forward reference issues: https://github.com/dlang/dmd/pull/2851

So the invalid front is supposed to be accepted (if it's never called)? Then I
suppose the accepts-invalid aspect of this issue is WONTFIX.

But it should link then, no?

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

--- Comment #7 from Vladimir Panteleev  ---
(In reply to ag0aep6g from comment #6)
> (In reply to Vladimir Panteleev from comment #3)
> > I'm closing this for now, but please reopen if you can provide a working
> > practical example.
> 
> Reduced accepts-invalid:

This is not a valid reduction because .front is never called. The compiler
seems to be skipping semantic analysis of uncalled functions here to avoid
forward reference issues: https://github.com/dlang/dmd/pull/2851

--

[Issue 17550] New: No Edits while Resharper Extension is active

[via Digitalmars-d-bugs]

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

  Issue ID: 17550
   Summary: No Edits while Resharper Extension is active
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: arbm...@gmail.com

I installed VisualD with Visual Studio 2017 Community Edition.
I tried first the latest 0.44.2 realease and the 0.45-beta1.
But the Editor does not allow me to edit any files.

When I disable the Jetbrain's Resharper Plugin it allows edits again.

I could not find any indication of this conflict. So I want to bring this to
your attention here. Even though it might be the fault of Jetbrain Resharper.

For the programmers like me, that have both installed it's a very frustrating
experience.

Maybe you can inspect the issue.
I know that Jetbrains offers free licenses for open source developers. If you
care enough to debug the issue.

I created a bug ticket for Resharper as well.
https://youtrack.jetbrains.com/issue/RSRP-465204

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ag0ae...@gmail.com
 Resolution|INVALID |---

--- Comment #6 from ag0ae...@gmail.com ---
(In reply to Vladimir Panteleev from comment #3)
> I'm closing this for now, but please reopen if you can provide a working
> practical example.

Reduced accepts-invalid:


enum e = is(typeof(map()));

struct MapResult()
{
this(char[] a) {}

char front()
{
dchar d;
return d; /* should fail compilation */
}
}

void map()()
{
auto mr = MapResult!()([]);
}

void main()
{
map();
}

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to ZombineDev from comment #4)
> Vladimir, shouldn't this bug be closed as "WORKSFORME", as the bug was that
> the compiler accepted the invalid example in the first place?

Well, the code wasn't technically invalid, just nonsensical. It stopped working
after this PR:

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

I'm not sure if that behavior change was intentional either, hence my comment
there.

There is also no practical difference between INVALID and WORKSFORME in
practice, I think.

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

--- Comment #4 from ZombineDev  ---
Vladimir, shouldn't this bug be closed as "WORKSFORME", as the bug was that the
compiler accepted the invalid example in the first place?

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #3 from Vladimir Panteleev  ---
The example presented is invalid, as the parameter of each is not expected to
return anything, and map is lazy and by itself does not mutate global state (is
pure if its predicate is). It also doesn't compile any more in the latest
version of D.

I'm closing this for now, but please reopen if you can provide a working
practical example.

--

[Issue 11092] @commutative annotation for commutative functions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
Please see https://github.com/dlang/DIPs#procedure for instructions on how to
propose a change in the language. Bugzilla is not the correct avenue for that.

--

[Issue 14256] Poor IO performance on 64-bit dmd 2.066 (OS X)

[via Digitalmars-d-bugs]

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

--- Comment #13 from Vladimir Panteleev  ---
(In reply to Ivan Kazmenko from comment #11)
> The current table:

Also, if you have a script that generates this table, posting it here would be
helpful.

--

[Issue 14256] Poor IO performance on 64-bit dmd 2.066 (OS X)

[via Digitalmars-d-bugs]

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

--- Comment #12 from Vladimir Panteleev  ---
Can you please test with -m32mscoff, in addition to -m32 and -m64?

I predict that the numbers are going to be very close to -m64. If so, then that
indicates that we are limited by Microsoft's C runtime, in which case there is
nothing that can be done short of rewriting std.stdio to not use C I/O.

--

[Issue 6904] Skip Setting up Stack Frame if No Stack is Used

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
I believe this was fixed by this pull request:
https://github.com/dlang/dmd/pull/5040

--

[Issue 14256] Poor IO performance on 64-bit dmd 2.066 (OS X)

[via Digitalmars-d-bugs]

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

Ivan Kazmenko  changed:

   What|Removed |Added

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

--- Comment #11 from Ivan Kazmenko  ---
I've just checked with a more recent version (dmd 2.074.1), and the picture is
the same as two years ago here (Win64, file is on SSD), so reopened.

In the readln program, I allocated buffer of 110 bytes (the posted version
had 1, and so failed on test 3).

The current table:

Entry   test1 test2 test3
Number of lines   100 1   100
Length of each line   100 1   100

Python 2.7.5 x32:0.68  0.44  0.36
Python 2.7.10 x64:   0.55  0.36  0.33
DMD 2.074.1 byLine -m32: 0.27  0.73  1.05
DMD 2.074.1 byLine -m64: 1.45  1.31  1.43
DMD 2.074.1 readln -m32: 0.25  0.63  1.00
DMD 2.074.1 readln -m64: 1.55  1.54  1.46
DMD 2.074.1 read+splitLines -m32:0.35  0.39  0.31
DMD 2.074.1 read+splitLines -m64:0.41  0.31  0.32

The times of 1 second or above are clearly problematic.

In Python, string storage is low-level but number of lines affects the Pythonic
part, so test1 is slower.

In D -m32, the byLine and readln versions are slower when the length of lines
grows, possibly due to reallocation when constructing a string.  I'd say 3x
slower than Python on large strings feels like too much.

In D -m64, the byLine and readln versions still take 1.3+ seconds on all tests,
more than 2x slower than Python, which is sad.

As earlier, the read+splitLines version is the fastest on all tests in both
-m32 and -m64, so speed is definitely possible, just not as out-of-the-box as
the other two versions.

Ivan Kazmenko.

--

[Issue 7103] the -property switch vs. template functions with default template arguments

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #2 from Vladimir Panteleev  ---
The -property switch has been deprecated and no longer has any effect, closing.

--

[Issue 10529] rmdirRecurse should have an optional force parameter for read-only file removal

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
(In reply to Andrej Mitrovic from comment #0)
> however Phobos lacks a 'setFileAttributes' function.

Added in https://github.com/dlang/phobos/pull/1804.

> I propose we add an optional 'force' enum or boolean to rmdirRecurse, 

I tried to add such a parameter to my own library (see forceDelete in
ae.sys.file), and quickly found myself entangled in a hairball of what "force"
really means.

On Windows, aside from the read-only file attribute, you also need to deal with
locked files. Unlike on POSIX, these files cannot be deleted, but they can be
moved, so the code could try renaming it to another location until they are
unlocked. On newer Windows versions, additionally, when attempting to delete a
directory in use by another application, the delete call succeeds, but the
directory remains in its parent directory's file listing, though completely
inaccessible until the program holding the lock on it releases the lock or
exits.

So, it's a mess. I suggest that instead of involving Phobos into this mess,
programs should explicitly deal with those situations that they expect they
will encounter. Arbitrarily needing to delete directories which MIGHT have a
read-only flag set is something that should actually be encountered rarely,
mainly when implementing file managers; in all other cases, the programs should
have some degree of expectations of which files or subdirectories are going to
have the read-only flag set, and deal with that explicitly. Functions which
attempt to "deal" with whatever situation comes up - when in reality most such
situations are going to be predictable - are, as I've learned, an anti-pattern,
and should be avoided.

--

[Issue 14256] Poor IO performance on 64-bit dmd 2.066 (OS X)

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #10 from Vladimir Panteleev  ---
>From a cursory benchmark, the D programs perform as well as or better than the
Python version for me, except for the splitLines version.

Note that splitLines also splits by Unicode line delimiters, not just \r and
\n, which is why it's slower. Replacing splitLines(s) with split(s, '\n') makes
the program much faster.

Please reopen if you think the problem persists.

--

[Issue 17438] std.conv.parse documentation contradiction

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
The documentation says:

Throws: A ConvException If an overflow occurred during conversion or if no
character of the input was meaningfully converted. 

"if no character of the input was meaningfully converted" is the key part, so
at least for the example you presented, I don't see a problem.

--

[Issue 7707] Purity inference fails when template used before it's defined

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #1 from Vladimir Panteleev  ---
This needs a self-contained test case.

Please reopen if you consider this issue still valid and can provide a
self-contained test case.

--

[Issue 12758] Compiler should infer acceptable module name when file name includes hyphens

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #8 from Vladimir Panteleev  ---
(In reply to yebblies from comment #6)
> I don't think the compiler should be guessing what you wanted the module to
> be called.

Indeed. It is by the same reasoning that the compiler will not do
case-insensitive lookup (on case-sensitive filesystems). Not only is this less
efficient (enumerating a directory can be much more inefficient than accessing
a file by its file name), but it creates problems such as multiple file names
mapping to the same module name (what if you have a-b.d and a_b.d in the same
directory?).

--

[Issue 16502] spawnProcess does not throw on exec errors

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #6 from greensunn...@gmail.com ---
> Fixed in https://github.com/dlang/phobos/pull/5431


@Roman: If you reference the Bugzilla issue(s) in your PRs, they will be
automatically closed & you don't need to keep track of them manually ;-)

https://github.com/dlang-bots/dlang-bot#automated-references

There are other advantages of doing this as well, e.g. referenced issues will
be listed on the changelog.

--

[Issue 15783] Junk is written into environment variable after assigning null to it

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #5 from greensunn...@gmail.com ---
@Roman: If you reference the Bugzilla issue(s) in your PRs, they will be
automatically closed:

https://github.com/dlang-bots/dlang-bot#automated-references

There are other advantages of doing this as well, e.g. referenced issues will
be listed on the changelog.

--

[Issue 8985] Get default parameter value as alias

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P2  |P3
 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|__parameters tuple string   |Get default parameter value
   |strips off the scope of |as alias
   |default args|
   Severity|normal  |enhancement

--- Comment #1 from Vladimir Panteleev  ---
The problem is not with __parameters, which works as expected. __parameters is
not a tuple string, it rather seems to be a tuple of types with default values
attached to them.

If there was a way to get said default value as an alias, then it would then be
possible to pass it to fullyQualifiedName to achieve your desired goal.

--

[Issue 16502] spawnProcess does not throw on exec errors

[via Digitalmars-d-bugs]

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

--- Comment #5 from Roman  ---
Fixed in https://github.com/dlang/phobos/pull/5431

--

[Issue 16502] spawnProcess does not throw on exec errors

[via Digitalmars-d-bugs]

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

Roman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15783] Junk is written into environment variable after assigning null to it

[via Digitalmars-d-bugs]

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

Roman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15783] Junk is written into environment variable after assigning null to it

[via Digitalmars-d-bugs]

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

--- Comment #4 from Roman  ---
Was fixed in https://github.com/dlang/phobos/pull/5324
Can we get this closed?

--

[Issue 7436] ICE(cg87.c) ubyte = ubyte op= float

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Kenji Hara from comment #4)
> Not all cases are fixed. See the disabled test cases in
> test/compilable/testexpression.d.

Bisection shows that the remaining cases were fixed (by you) in
https://github.com/dlang/dmd/pull/4415.

--

[Issue 17548] [REG2.072.0] Forward reference error with scope function parameters

[via Digitalmars-d-bugs]

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

johanenge...@weka.io changed:

   What|Removed |Added

 CC||johanenge...@weka.io

--- Comment #2 from johanenge...@weka.io ---
https://github.com/dlang/dmd/pull/6934

--

[Issue 17549] New: $($1) should expand to the macro identified by $1

[via Digitalmars-d-bugs]

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

  Issue ID: 17549
   Summary: $($1) should expand to the macro identified by $1
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ddoc
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

Given a DDoc file:

// test.dd //
Ddoc

$(FOO BAR)

Macros:

BAR=bar
FOO=$($1)
/

DMD will currently emit:

$(BAR)

This result is not what was intended, and not useful.

Allowing specifying and expanding macros by their name via macro parameters
would allow using new DDoc patterns, similar to the X macro preprocessor
pattern in C.

Example use case:

https://github.com/dlang/dlang.org/pull/1766#discussion_r123892968

--

[Issue 17548] [REG2.072.0] Forward reference error with scope function parameters

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|Forward reference error |[REG2.072.0] Forward
   |with scope function |reference error with scope
   |parameters  |function parameters
   Severity|major   |regression

--- Comment #1 from Vladimir Panteleev  ---
This seems to be a regression.

Introduced in https://github.com/dlang/dmd/pull/6001

--