[Issue 9766] align(n) with n compile-time constant

[via Digitalmars-d-bugs]

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

--- Comment #5 from j...@red.email.ne.jp ---
Some of druntime core.sys.windows.* modules also want this,

Like:
version (Win64) align(8):
else align(4):

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

We could make work-around with string-mixin above.

However, I think this is an essential feature for D.

--

[Issue 15839] [REG2.071-b1] this.outer is of wrong type

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/a117c87a8a9ffbccc78b2c28ae3643b5e5b02794
Fix invalid AST produced by issue 15839 fix

The fix for 15839 (accessing this.outer from a member function
inside a nested class) in bb5f550edd7 produces a ThisExp that
refers to the 'this' VarDecl in an outer scope, leading to the
latter being referenced from the nested scope without that being
added to its nestedRefs. Subsequently, the VarDecl is also not
present in the outer FuncDecls closureVars.

This is a weird construct, and outside the AST invariants that
would previously hold. This commit properly at least properly
registers the nested reference, but using a ThisExp in this
manner might not be the cleanest way in the first place.

https://github.com/dlang/dmd/commit/d178c8578e615c3e68702905b72c3e89bccbecd6
Merge pull request #5741 from klickverbot/fixup-15839-ast

Fix invalid AST produced by issue 15839 fix

--

[Issue 13532] std.regex performance (enums; regex vs ctRegex)

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Dmitry Olshansky from comment #4)
> (In reply to Vladimir Panteleev from comment #2)
> > Well, it's slower for this particular case, not necessarily in general.
> > CCing Dmitry.
> 
> Please try with https://github.com/D-Programming-Language/phobos/pull/4147

As before (all changes are at most 20% since 2014).

--

[Issue 11229] std.string.toLower is slow

[via Digitalmars-d-bugs]

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

--- Comment #7 from Jon Degenhardt  ---
Similar to the previous comment, I tried an alternate implementation for
std.uni.asLowerCase using map with std.uni.toLower (the single character
version). The single character toLower already has the ascii check
optimization.

Timing with LDC was improved in all cases. 2.5-3x for latin languages, 1.5-2x
for Japanese and Chinese. For DMD the improvements were 5x-20x, depending on
whether depending on latin vs asian text and whether decoding to dchar was
included or not.

Program used to do timing is here: https://dpaste.dzfl.pl/a0e2fa1c71fd

Texts used for timing were books in several languages found on the Project
Gutenberg site (http://www.gutenberg.org/), with the boilerplate text removed.
Latin languages tested were in English, Finnish, German, Spanish. 

Timing was done on OSX; DMD 2.071 (-release -O -boundscheck=off -inline); LDC
1.0.0-beta1 (Phobos 2.070.2; -release -O -boundscheck=off).

That the Japanese and Chinese language docs showed improvement suggests the map
+ toLower was faster than std.uni.asLowerCase apart from the ascii
optimization. Texts used for these had only about 3% ascii characters, so the
optimization was rarely used.

The replacement for asLowerCase I used is:

auto mapAsLowerCase(Range)(Range str)
if (isInputRange!Range && isSomeChar!(ElementEncodingType!Range) &&
!isConvertibleToString!Range)
{
static if (ElementEncodingType!Range.sizeof < dchar.sizeof)
{
import std.utf : byDchar;
return str.byDchar.mapAsLowerCase;
}
else
{
import std.algorithm : map;
import std.uni : toLower;

return str.map!(x => x.toLower);
}
}

--

[Issue 16004] Document changes to protection attributes

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

Summary|Properly document changes   |Document changes to
   |to protection attributes|protection attributes

--

[Issue 16004] New: Properly document changes to protection attributes

[via Digitalmars-d-bugs]

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

  Issue ID: 16004
   Summary: Properly document changes to protection attributes
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: mathias.l...@sociomantic.com
CC: c...@dawg.eu

Since 2.071, protection attributes is a misnomer, since it now participates in
symbol lookup.
`private` symbols won't conflict with same-named symbols in other modules for
example, however the specs (
http://dlang.org/spec/attribute.html#ProtectionAttribute ) currently says
otherwise. Hence this section is in need of a rename / overhaul.

For reference, two links where the new behaviour was discussed:
- DIP22 implementation: https://github.com/dlang/dmd/pull/5472
- Martin's comment in 15897: https://issues.dlang.org/show_bug.cgi?id=15897#c12

Name lookup is also not documented in the specs, and it might be worth making
visibility and lookup rules be in their own, dedicated section.

Leaving aside the current bugs, name lookup is now performed in two phases:
- First local declarations / member of the scope
- Then imports of that scope

Scopes are considered in the following order:
A) Local
B) Mixin templates
C) Base class
D) Enclosing scope (starting from step A)

Note: For the import part, there is an issue opened:
https://issues.dlang.org/show_bug.cgi?id=15966

The underlying reason for this order is to forbid any local symbol hijacking
(imported symbol hijacking is still possible) if a module introduces a new
symbol.

--

[Issue 16003] stringof for module doesn't include full path

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME
   Severity|blocker |normal

--- Comment #2 from Dmitry Olshansky  ---
There is a way to get module's parent with __traits(parent, ...) so closing
this.

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

[via Digitalmars-d-bugs]

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

--- Comment #11 from Martin Nowak  ---
Having the main thread hang while waiting for semaphore posts in the
thread_suspendAll is a good indication that the signal was lost.
Did you have gdb attached while the signal was send? That sometime causes
issues w/ signal delivery.
The setup looks fairly simple (a few threads allocating classes and extending
arrays) to be run for a few days, maybe we can reproduce the problem.

Are there any other reasons for switching to real-time signals?
Which real-time signals are usually not used for other purposes?

--

[Issue 16003] stringof for module doesn't include full path

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Severity|enhancement |blocker

--- Comment #1 from Dmitry Olshansky  ---
This blocks a new DIP on exceptions. See brief outline here:
https://github.com/dlang/phobos/pull/3491

--

[Issue 16003] New: stringof for module doesn't include full path

[via Digitalmars-d-bugs]

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

  Issue ID: 16003
   Summary: stringof for module doesn't include full path
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dmitry.o...@gmail.com

import std.stdio;
pragma(msg, std.stdio);

Prints:
module stdio

Would be useful if it printed "module std.stdio" as it's more complete
information.

--