[Issue 17962] dirEntries now truncates Unicode file names

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17962

--- Comment #1 from Jonathan M Davis  ---
https://github.com/dlang/phobos/pull/5838

--

[Issue 17962] New: dirEntries now truncates Unicode file names

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17962

  Issue ID: 17962
   Summary: dirEntries now truncates Unicode file names
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: issues.dl...@jmdavisprog.com

Thanks to https://github.com/dlang/phobos/pull/5758 (which I _think_ is just on
master and didn't make it into 2.077), std.file.dirEntries can no longer handle
Unicode file names. It now incorrectly combines countUntil with slicing a
string, and Unicode names get truncated.

For instance, if you do something like

foreach(de; dirEntries("foo", SpanMode.shallow))
{
if(de.isDir)
{
}
}

and the directory foo contains a file name with Unicode characters, then isDir
will throw a FileException, because de.name does not actually exist (since the
file's name was truncated).

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17914

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #12 from Steven Schveighoffer  ---
Not fixed yet, still waiting for: https://github.com/dlang/phobos/pull/5835

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17914

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

https://github.com/dlang/druntime/commit/9fee0ca6365408d753aedb517c0896af36966b65
Merge pull request #1966 from nemanja-boric-sociomantic/fiber-docs

Fix issue 17914: Document connection between fiber guard and mmap limit
merged-on-behalf-of: Steven Schveighoffer 

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17961

--- Comment #3 from hst...@quickfur.ath.cx ---
P.S., this bug pertains to Phobos git HEAD, not to any release (that I'm aware
of).

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17961

hst...@quickfur.ath.cx changed:

   What|Removed |Added

Summary|Git HEAD std.uni does not   |std.uni does not compile
   |compile with -unittest  |with -unittest -dip1000
   |-dip1000|

--

[Issue 17961] Git HEAD std.uni does not compile with -unittest -dip1000

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17961

--- Comment #2 from hst...@quickfur.ath.cx ---
Found the offending commit: 905788a65a4b7833f52ee0701dc919ee54f0d35b (Phobos PR
#5337).

--

[Issue 17961] Git HEAD std.uni does not compile with -unittest -dip1000

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17961

--- Comment #1 from hst...@quickfur.ath.cx ---
P.S. This bug is causing my otherwise-dip1000-compliant code to no longer
compile, making it impossible to build the code with dip1000 (unless I disable
-unittest, but that's not a practical workaround during development).

--

[Issue 17961] New: Git HEAD std.uni does not compile with -unittest -dip1000

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17961

  Issue ID: 17961
   Summary: Git HEAD std.uni does not compile with -unittest
-dip1000
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
---
/* test.d */
import std.uni;
---

Compile command:
---
dmd -dip1000 -unittest -c test.d
---

Compiler output:
---
/usr/src/d/phobos/std/uni.d(2554): Error: reference to local variable
__tmpfordtor853 assigned to non-scope parameter this calling
std.uni.InversionList!(GcPolicy).InversionList.byInterval
/usr/src/d/phobos/std/uni.d(1976): Error: template instance
std.uni.InversionList!(GcPolicy) error instantiating
---

This used to work fine until recently. Will post an update once I finish git
bisecting.

--

[Issue 7184] parse error on *(x)++

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #2 from anonymous4  ---
Is the grammar ordered? It expects braces through PowExpression:
https://dlang.org/spec/grammar.html#PowExpression

--

[Issue 4946] Not good error message with wrongly positioned 'const'

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=4946

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #2 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/7280

--

[Issue 17957] D shared library throws asserts when called from C detached pthread but not terminated with dlclose

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17957

--- Comment #2 from Nicolas F.  ---
(In reply to ponce from comment #1)
> A major problem I see is that you use pthread_detach which you are not
> supposed to. 
> 
> People are talking about "attachment" in the context of the D runtime which
> maintains a list of "attached" threads
> (thread_attachThis/thread_detachThis), nothing to do with pthreads.
> 
> In your case, you don't want the runtime enabled so don't have to worry
> about this attachment to the D runtime anyway.

This is just a minimal test application which shows exactly the behaviour that
is causing an issue. The place I ran onto this in the real world is when trying
to write a SO plugin for mpv. mpv spawns SO plugins in a detached thread, and I
have no control over this. Ideally I'd use the runtime within my thread in that
case so I can get things like the GC, but this issue happens both with the
runtime initialised and without.

There really is no reason for D to segfault or throw asserts at all if the
parent application doesn't call dlclose() before shutting down.

--

[Issue 17957] D shared library throws asserts when called from C detached pthread but not terminated with dlclose

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17957

ponce  changed:

   What|Removed |Added

 CC||alil...@gmail.com

--- Comment #1 from ponce  ---
A major problem I see is that you use pthread_detach which you are not supposed
to. 

People are talking about "attachment" in the context of the D runtime which
maintains a list of "attached" threads (thread_attachThis/thread_detachThis),
nothing to do with pthreads.

In your case, you don't want the runtime enabled so don't have to worry about
this attachment to the D runtime anyway.

--

[Issue 780] (D1 only) The assignment of 'this' is allowed

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=780

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #10 from Steven Schveighoffer  ---
Companies such as Sociomantic still uses D1 for now, and have certainly been
able to get D1 fixes through when they need it. So D1 isn't quite "dead" yet.

In this particular case, I tend to agree that it's likely not going to be
addressed as it doesn't really affect any "good" code.

But until Walter says "no more D1 fixes period", we should at least leave the
bug reports for D1 open.

I'd also suggest that at some point, if D1 is truly dead, we don't "close" all
these issues, because anyone who may still use D1 may want to know what issues
haven't been fixed (and won't be). Perhaps a new status type can be added, not
sure how customizable bugzilla is in this regard.

Alternatively, we can fork bugzilla into another location where D1 bugs don't
interfere with D2 reports.

--

[Issue 13041] std.range.transposed consumes sub-ranges

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13041

--- Comment #4 from Steven Schveighoffer  ---
It certainly is possible. Note there is current work to update Transposed to
use transverse to allow indexing https://github.com/dlang/phobos/pull/5805.

I think we can go further building upon transverse, and its related option on
how to treat the data.

But it would be a strange relationship between transposed and its subranges. If
the subranges were indexable, then Transposed can be a forward range, otherwise
it can't. Seems unintuitive, and not sure it's worth all the effort.

In other cases as well (if, for instance, the RangeOfRanges stores everything
by value), then save could also be implemented. We may have a hard time
detecting this because the relationship between Transposed and whether it's
valid to make a copy is confusing and not well-established.

--

[Issue 257] package vars accessible from sub-modules, package funcs not

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=257

RazvanN  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #2 from RazvanN  ---
(In reply to Jarrett Billingsley from comment #0)
>  modules/mymod.d --
> 
> module modules.mymod;
> 
> package int foo;
> 
> package void bar()
> {
> 
> }
> 
>  modules/level/test.d --
> 
> module modules.level.test;
> 
> import modules.mymod;
> 
> void f()
> {
>   foo = 1;
>   bar();
> }
> 
> 
> 
> Compiling those gives an error when trying to access bar() from test, but
> accessing foo is OK.
> 
> Moreover, 
> 
>  modules/mymod2.d --
> 
> module modules.mymod2; // notice it's in the same package as mymod
> 
> import modules.mymod;
> 
> void f()
> {
>   foo = 1;
>   bar();
> }
> 
> --
> 
> Works, as expected, just fine.
> 
> If I'm reading the spec correctly, neither foo or bar() should be accessible
> from test, as only modules in the same package (i.e. other modules in the
> "modules" package; test is in "modules.level") should be able to access them.
> 
> I'm flagging this as accepts-invalid, as you can access foo, when I don't
> think you should.

Compiling both examples on Ubuntu 16.04 and Windows (via wine) with git HEAD
results in successful compilation as it should. modules/level/test is a
subpackage of the package modules and is considered to be in the same package
as mymod. Therefore, both package members bar and foo should be accesible and
they are. Closing as fixed.

--

[Issue 16564] KRRegion.empty sometimes returns Ternary.no

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16564

Lucia Cojocaru  changed:

   What|Removed |Added

   Assignee|lucia.mcojoc...@gmail.com   |nob...@puremagic.com

--

[Issue 16656] move embedded zlib to a separate library

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16656

Lucia Cojocaru  changed:

   What|Removed |Added

   Assignee|lucia.mcojoc...@gmail.com   |nob...@puremagic.com

--

[Issue 7184] parse error on *(x)++

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=7184

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from RazvanN  ---
Issuing an error is the correct behavior. As you can see in the grammar [1], 
*(x)++ is parsed the following way: *UnaryExpression. If a parenthesis is
encountered, then the parser expects a type :
(type).identifier/templateInstance.
Since none of the above is actually encountered, the parser presumes you tried
to do a C style cast. Note that dropping the useless parens or doing *((x))++
works since the parser then knows that the outermost () hold a primary
expression.

The behavior is according to the spec, so I will close this as invalid. 

[1] https://dlang.org/spec/grammar.html#UnaryExpression

--

[Issue 17940] bool function parameters loaded from struct sometimes miscompiled with -O

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17940

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

   What|Removed |Added

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

--

[Issue 17940] bool function parameters loaded from struct sometimes miscompiled with -O

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17940

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

https://github.com/dlang/dmd/commit/87cd61e4c4aca33254bacb2af735433193a51039
fix issue 17940
When generating a 1-byte mov cse on x86_64, handle the REX
flag after setReg, instead of when the instruction is first
created, since that's when we know if we need it.

https://github.com/dlang/dmd/commit/89b0af132529d4635717fd4b16ffc300056dd1b9
Merge pull request #7252 from FeepingCreature/master

fix issue 17940 - always set REX for 1-byte CSE moves on x86_64
merged-on-behalf-of: Walter Bright 

--

[Issue 17960] [REG 2.077-rc1] A 192 bytes leak is created by the GC when `-unittest` is an option

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17960

--- Comment #1 from b2.t...@gmx.com ---
Actually this is minor issue. Importnat thing being "definitely lost: 0 bytes
in 0 blocks".

--

[Issue 17769] dmd accepts conversion from shared(int)* to int* when value comes from method

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17769

--- Comment #1 from Lucia Cojocaru  ---
The reason for the bug is that there are different overloads in dcast.d for
implicitConvTo for CallExp (int* foo = s.method() falling here) and Expression
(where the other examples in this issue go).
https://github.com/dlang/dmd/blob/master/src/ddmd/dcast.d#L179

Expression: https://github.com/dlang/dmd/blob/master/src/ddmd/dcast.d#L194
CallExp: https://github.com/dlang/dmd/blob/master/src/ddmd/dcast.d#L809

For: int* foo = s.method(); 
Code goes into visit(CallExp) and calls visit(Expression) which defaults to
NOMATCH(false).
https://github.com/dlang/dmd/blob/master/src/ddmd/dcast.d#L817

On NOMATCH, the checks continue in visit(CallExp) and if nothing is found, it
dafaults to success (true).
https://github.com/dlang/dmd/blob/master/src/ddmd/dcast.d#L940


Everything else hits the default in visit(Expression) which is NOMATCH - hence
the rejecting.

Now I have a fix here disallowing pointer conversions from shared to nonshared
https://github.com/somzzz/dmd/commit/6fdead01822071b464016f1c0313358f40494de2

But DIP29 allows this kind of conversions as long as the pointers are unique.
https://wiki.dlang.org/DIP29

This results in my fix breaking the following compiler tests for DIP29:
https://github.com/dlang/dmd/blob/master/test/runnable/implicit.d#L217

I'm not sure how to check if the pointer is unique. Also, are there any other
subtleties related to DIP29 that these changes could be disregarding?

--

[Issue 780] (D1 only) The assignment of 'this' is allowed

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=780

--- Comment #9 from RazvanN  ---
(In reply to Steven Schveighoffer from comment #8)
> Reopening, this is a D1 only bug. I'm not in a position to test, but I can't
> tell if you mean that you tested on the HEAD for D1 or not. I can't imagine
> this got fixed by accident in D1.

Sorry for my lack of rigorousness. I tested on D2. My understanding is that D1
is not maintained anymore so I don't see the point in keeping bugs for D1 in
bugzilla.

--

[Issue 16313] Duplicate symbol generated

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16313

RazvanN  changed:

   What|Removed |Added

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

--- Comment #4 from RazvanN  ---
(In reply to Jorge Lima from comment #3)
> (In reply to RazvanN from comment #2)
> > Just tested on Windows with git HEAD and the issue is still present. On
> > Ubuntu 16.04 the issue is not present. Changing description to Windows
> 
> I tested before with release 2.072.0 and the problem was fixed. See my
> previous comment from 2016-11-25. However. at the time, I didn't check on
> all platforms
> Triggered by your comment, I tested now the release 2.076.1 on the following
> platforms
> 
> Ubuntu 16.04 64bit: passed 
> OS X 10.10: passed
> Windows 10 64bit: failed but due to a different issue. See below.
> 
> > dmd snippet.d
> OPTLINK (R) for Win32  Release 8.00.17
> Copyright (C) Digital Mars 1989-2013  All rights reserved.
> http://www.digitalmars.com/ctg/optlink.html
> teste.obj(teste)  Offset 00370H Record Type 009D
>  Error 16: Index Range
> Error: linker exited with status 1
> 
> I noticed OPTLINK is for Win32. Weird! So I passed the option -m64 to dmd
> to force it to use the microsoft linker.
> 
> > dmd -m64 snippet.d
> 
> And it compiled the snippet without errors.
> 
> So I would say this problem seems to be fixed!

Cool! I had the same error weird error and I thought that was the issue. Thanks
a lot. Closing as fixed

--

[Issue 17960] New: [REG 2.077-rc1] A 192 bytes leak is created by the GC when `-unittest` is an option

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17960

  Issue ID: 17960
   Summary: [REG 2.077-rc1] A 192 bytes leak is created by the GC
when `-unittest` is an option
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

with DMD 2.077-rc1


--- a.d ---
void main(){}
---

dmd a.d -unittest && valgrind --leak-check=yes ./a

gives:

---
==23681== HEAP SUMMARY:
==23681== in use at exit: 192 bytes in 1 blocks
==23681==   total heap usage: 109 allocs, 108 frees, 55,864 bytes allocated
==23681== 
==23681== LEAK SUMMARY:
==23681==definitely lost: 0 bytes in 0 blocks
==23681==indirectly lost: 0 bytes in 0 blocks
==23681==  possibly lost: 0 bytes in 0 blocks
==23681==still reachable: 192 bytes in 1 blocks
==23681== suppressed: 0 bytes in 0 blocks
==23681== Reachable blocks (those to which a pointer was found) are not shown.
==23681== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==23681== 
==23681== For counts of detected and suppressed errors, rerun with: -v
==23681== Use --track-origins=yes to see where uninitialised values come from
==23681== ERROR SUMMARY: 254 errors from 12 contexts (suppressed: 0 from 0)
---

The problem disappears without -unittest.

--

[Issue 17943] Wrong pointer arithmetic optimization

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17943

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

https://github.com/dlang/dmd/commit/b8a263d2aa7a2091d95dc6f57fd06f1315b5c9fa
Fix issue 17943 - Wrong pointer arithmetic optimization

https://github.com/dlang/dmd/commit/a244ac72197211d94be965ce09a5f84be2ac09e4
Merge pull request #7269 from yshui/17943

--

[Issue 17915] [REG 2.073] core.exception.AssertError@ddmd/optimize.d(614): Assertion failure

2017-11-02 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17915

Walter Bright  changed:

   What|Removed |Added

   Keywords||ice
 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7278

--