[Issue 16288] splitter() that doesn't eat sentinels

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16288

--- Comment #3 from Jack Stouffer  ---
(In reply to Manu from comment #2)
> That's fine.
> Does that already exist? I couldn't see anything on dlang.org.
> 
> Obviously the Pred function should remain as the first template arg, it can
> be second...

It's in the nightlies and on the prerelease docs.

--

[Issue 16295] New: REG since 2.069: undefined symbol that should be defined

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16295

  Issue ID: 16295
   Summary: REG since 2.069: undefined symbol that should be
defined
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

out_D=/tmp/

dmd=$dmd_069_X
# dmd=$dmd_068_X
# dmd=$ldc_X

$dmd -c -of$out_D/main.o main.d && nm $out_D/main.o | grep ' U _D4main8__'

For dmd v2.071.1 and dmd v2.069, we these undefined symbols; the ones starting
with _D4main8_ should not be undefined:

U _D15TypeInfo_Struct6__vtblZ
U _D4main8__T1AThZ1A8__T1BThZ1B5emptyMFNaNbNdNiNfZi
U _D4main8__T1AThZ1A8__T1BThZ1B5frontMFNaNbNiNfZPv
U _D4main8__T1AThZ1A8__T1BThZ1B8popFrontMFNaNbNiNfZv
U __d_arraybounds
U __d_assert
U __d_assert_msg
U __d_unittest

eg, _D4main8__T1AThZ1A8__T1BThZ1B5frontMFNaNbNiNfZPv corresponds to:
pure nothrow @nogc @safe void* main.A!(ubyte).A.B!(ubyte).B.front()

For ldc (based on DMD v2.071.1 and LLVM 3.8.0) and dmd dmd v2.068, we get the
correct undefined symbols:
U _D15TypeInfo_Struct6__vtblZ
U __d_arraybounds
U __d_assert
U __d_assert_msg
U __d_unittest



fun.d:

import main;
void fun(A!(ubyte) a){
}

main.d:

module main;
import fun;

struct A(T)
{
void test()
{
foreach (v; this)
{
}
}

auto range()
{
return B!T();
}

int opApply(int delegate(T))
{
auto r = range;
foreach (v; r)
{
}
return 0;
}

struct B(T)
{
auto front()
{
void* a;
return a;
}

@property empty()
{
return 0;
}

void popFront()
{
}
}

}

alias Au = A!(ubyte);

--

[Issue 16287] update mixin template specs to reflect new import rules (as of 2.071)

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16287

--- Comment #2 from det <2k...@gmx.net> ---
https://issues.dlang.org/show_bug.cgi?id=16004 is certainly related therefore i
added a 'see also' link. however i don't think it is fully sufficient WRT mixin
templates. spec changes that especially effect mixin templates and are at odds
with the current explanation of how mixin templates work require a fix in the
documentation of mixin templates as well. remember, whole module imports
through mixin templates used to work and the specs rather indicate that it
should. for any problem encountered with mixin templates ppl will refer to the
mixin template specs first, because it is understood that mixin templates do
something extraordinary, represent a special case. also, to fix old code /
write intelligent new code one needs to know that there is (now) only a (new)
limitation with respect to whole module imports, not selective imports.

the new import rules require 3 distinct fixes / clarifications in the specs:
1) better coverage of protection attributes
2) (enforcement of) (scoped) import rules and lookup sequence in general
3) special case: mixin templates which IS different from (2)

as i understand it, https://issues.dlang.org/show_bug.cgi?id=16004 aims at (1)
and (2) only.

--

[Issue 16004] Document changes to protection attributes

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16004

det <2k...@gmx.net> changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16287

--

[Issue 16287] update mixin template specs to reflect new import rules (as of 2.071)

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16287

det <2k...@gmx.net> changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16004

--

[Issue 16294] New: import treated as public import

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16294

  Issue ID: 16294
   Summary: import treated as public import
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

This is inconsistent:
version(with_import)
should not affect visibility of symbol bar, given that we have 'import test3'
but not 'public import test3'



dmd -c -o- -version=with_import main.d
ok

dmd -c -o- main.d
test.d(2): Error: module test4 import 'bar' not found

using DMD64 D Compiler v2.071.1

main.d:
import test;

test.d:
import test4:bar;

test3.d:
void bar();

test4.d:
version(with_import)
import test3;

--

[Issue 16288] splitter() that doesn't eat sentinels

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16288

--- Comment #2 from Manu  ---
That's fine.
Does that already exist? I couldn't see anything on dlang.org.

Obviously the Pred function should remain as the first template arg, it can be
second...

--

[Issue 16293] New: hashOf should be @nogc when it can be

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16293

  Issue ID: 16293
   Summary: hashOf should be @nogc when it can be
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: joeyemm...@yahoo.com

What the title says, hashOf should be @nogc when it can be. 

In most cases it can be but bytesHash is not marked as @nogc even though I am
pretty sure it could be, meaning all the versions of hashOf that depend on it
can't be marked either.

--

[Issue 16283] [Modules]

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16283

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #8 from Steven Schveighoffer  ---
Sorry, but that's lazy. We can easily express the grammar that a module cannot
have a constructor (in contrast to your analogy, there is a separate module
grammar from classes, so we have a perfect spot to outlaw it).

We put up with a lot of grammar inaccuracies that result in simply ignored
attributes. We can do better.

Even if the actual code treats the grammar for modules and classes the same,
the documentation can reflect the actual result. Right now, it looks like
constructors are allowed.

CC grammar guru Brian

--

[Issue 16292] New: [REG2.069] bogus "Error: goto skips declaration of variable"

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16292

  Issue ID: 16292
   Summary: [REG2.069] bogus "Error: goto skips declaration of
variable"
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: rejects-valid
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

void main()
{
goto label; /* Error: goto skips declaration of variable test.main.__dop51
at test.d(4) */
if (makeS()[0]) /* line 4 */
{
label:
}
}

S makeS() { return S(); }

struct S
{
int opIndex(size_t i) { return 0; }
}

--

[Issue 16288] splitter() that doesn't eat sentinels

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16288

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
Does std.regex.splitter!(Yes.keepSeparators) suffice?

--

[Issue 16291] New: phobosinit fails to register encodings on individual tests

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16291

  Issue ID: 16291
   Summary: phobosinit fails to register encodings on individual
tests
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

make -f posix.mak std/encoding.test

std.encoding.EncodingException@std/encoding.d(2308): Unrecognized Encoding:
utf-16le

See also: https://github.com/dlang/phobos/pull/4493
& https://github.com/dlang/phobos/pull/4587

-

std.net.curl is affected too:

make -f posix.mak std/net/curl.test

std.encoding.EncodingException@std/encoding.d(2308): Unrecognized Encoding:
ISO-8859-1

--

[Issue 16259] entropy in std.numeric fails in release unittest

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16259

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from greenify  ---


*** This issue has been marked as a duplicate of issue 16227 ***

--

[Issue 16227] std.numeric unit tests fail when run in isolation

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16227

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #2 from greenify  ---
For a workaround see https://github.com/dlang/phobos/pull/4587.

--

[Issue 14477] Nullable does not work with structs with default constructor disabled

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14477

Justin Whear  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #2 from Justin Whear  ---
Afraid not.

--

[Issue 16289] no extern(C++) mangling for size_t/unsigned long parameters

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16289

--- Comment #1 from Martin Nowak  ---
It's possible to use cpp_ulong which get's the correct mangling, but it's
fairly unfriendly to use.
https://github.com/dlang/druntime/blob/fb0dafb741d33ae030c2e7a96bee2c61aa4d3cb4/src/core/stdc/config.d#L91

--

[Issue 16290] New: Problems with -fPIC, libraries and exceptions

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16290

  Issue ID: 16290
   Summary: Problems with -fPIC, libraries and exceptions
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: er.kr...@gmail.com

Hi!

I've stumbled across the following problem: when I raise an exception from a
(statically linked) library that was compiled with -fPIC, I get a segmentation
fault. Example:

-- libfoo/dub.json
{
"name" : "foo",
"description" : "Exception raising lib",
"dflags" : [ "-fPIC" ]
}
--
-- libfoo/source/foo.d
module foo;

public void throwIt() {
throw new Exception("This is an exception!");
}
--
-- bar/dub.json
{
"name" : "bar",
"description" : "uses libfoo",
"dependencies" : { "foo" : "*" },
}
-- bar/source/app.d
import foo;

void main() {
throwIt();
}
--

If I run "bar" (after libfoo is added through "dub add-local", of course), I
get a segmentation fault (the exception cannot even be caught). If I remove
"-fPIC" I get the usual stack trace and I can catch the exception as well.

Is this a compiler bug or is there a reason for that? I'm using "DMD64 D
Compiler v2.071.1", and it works properly both with gdc and ldmd2.

P.S.: This is simplified test case, the reason why I'm trying -fPIC is because
I want to link a dependency statically in a .so file which in turn will be
dynamically loaded as a plugin.

--

[Issue 16289] no extern(C++) mangling for unsigned long

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16289

Martin Nowak  changed:

   What|Removed |Added

 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 16289] no extern(C++) mangling for size_t/unsigned long parameters

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16289

Martin Nowak  changed:

   What|Removed |Added

Summary|no extern(C++) mangling for |no extern(C++) mangling for
   |unsigned long   |size_t/unsigned long
   ||parameters

--

[Issue 16289] New: no extern(C++) mangling for unsigned long

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16289

  Issue ID: 16289
   Summary: no extern(C++) mangling for unsigned long
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

The C++ mangler conflates mangling for unsigned, unsigned long, and unsigned
long long depending on the target architecture. Those are separate manglings in
C++, independent of their target size.
This leads to several linking problems w/ C++ code, in particular when a size_t
parameter is involved.
We already have some places in cppmangle where we properly handle
Id.__c_long/Id.__c_ulong. This should be extended to size_t parameters in
extern(C++) functions. We might also consider to change the size_t declaration
to exactly match the C++ definition of the used platform.

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16107

--- Comment #4 from b2.t...@gmx.com ---
ping. do you realize that by nature this bug is very disruptive ? It kills the
boolean logic.

--

[Issue 16288] New: splitter() that doesn't eat sentinels

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16288

  Issue ID: 16288
   Summary: splitter() that doesn't eat sentinels
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

I want a version of splitter that doesn't eat the sentinels.
I want to split AT the sentinels, but the sentinel should be the first
element of the bucket.

eg: assert(equal(splitter("hello  world", ' '), [ "hello", " ", " world" ]));

Note the weird behaviour since there are 2 spaces. More useful when
the data is not strings.

--

[Issue 14477] Nullable does not work with structs with default constructor disabled

2016-07-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14477

MichaelZ  changed:

   What|Removed |Added

 CC||dlang@bregalad.de

--- Comment #1 from MichaelZ  ---
I see the pull-request from when this issue was filed was retracted, as this is
evidently - in terms of implementation - a lot more subtle than it initially
sounds.

Is it really still being worked on?

--