[Issue 16596] `digger build` fails:Undefined symbols for architecture x86_64 symboldata

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16596

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
Perhaps try a digger build bisection (bisectBuild=true).

--

[Issue 16596] New: `digger build` fails:Undefined symbols for architecture x86_64 symboldata

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16596

  Issue ID: 16596
   Summary: `digger build` fails:Undefined symbols for
architecture x86_64 symboldata
   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

```
digger: Updating repo...
Fetching origin
digger: Starting at meta repository commit
546a7b9406a70b987e58ca3b0ee08e2d2d682f32
digger: Building components dmd, druntime, phobos-includes, phobos, rdmd
digger: needInstalled:
dmd-6269887e27c9f3c097e76f7d49e0cafce91265b7-4cc462583eb41c5436f6a8f5a3ffe12e
digger: Clearing temporary cache
digger: Cache miss.
digger: needBuild:
dmd-6269887e27c9f3c097e76f7d49e0cafce91265b7-4cc462583eb41c5436f6a8f5a3ffe12e
digger: Initializing and updating submodule dmd...
Submodule 'dmd' (git://github.com/D-Programming-Language/dmd) registered for
path 'dmd'
Cloning into '/Users/timothee/.config/digger/repo/dmd'...
Submodule path 'dmd': checked out '6269887e27c9f3c097e76f7d49e0cafce91265b7'
digger: Cleaning repository dmd...
HEAD is now at 6269887 Merge pull request #6153 from WalterBright/genhelpers
digger: Building
dmd-6269887e27c9f3c097e76f7d49e0cafce91265b7-4cc462583eb41c5436f6a8f5a3ffe12e
digger: Preparing DMD v2.067.1

CC=c++ /Users/timothee/.config/digger/dl/dmd-2.067.1/dmd2/osx/bin/dmd -ofdmd
-m64 -vtls -J. -L-lstdc++ -version=MARS -wi access.d aggregate.d aliasthis.d
apply.d argtypes.d arrayop.d arraytypes.d attrib.d builtin.d canthrow.d clone.d
complex.d cond.d constfold.d cppmangle.d ctfeexpr.d dcast.d dclass.d
declaration.d delegatize.d denum.d dimport.d dinifile.d dinterpret.d dmacro.d
dmangle.d dmodule.d doc.d dscope.d dstruct.d dsymbol.d dtemplate.d dversion.d
entity.d errors.d escape.d expression.d func.d globals.d hdrgen.d id.d
identifier.d impcnvtab.d imphint.d init.d inline.d intrange.d json.d lexer.d
lib.d link.d mars.d mtype.d nogc.d nspace.d opover.d optimize.d parse.d
sapply.d sideeffect.d statement.d staticassert.d target.d tokens.d traits.d
utf.d visitor.d typinf.d utils.d statementsem.d safe.d objc.d libmach.d
scanmach.d irstate.d toelfdebug.d toctype.d glue.d gluelayer.d todt.d tocsym.d
toir.d dmsc.d backend/bcomplex.d backend/cc.d backend/cdef.d backend/cgcv.d
backend/code.d backend/dt.d backend/el.d backend/global.d backend/obj.d
backend/oper.d backend/outbuf.d backend/rtlsym.d backend/ty.d backend/type.d
tk/dlist.d root/aav.d root/array.d root/ctfloat.d root/file.d root/filename.d
root/man.d root/outbuffer.d root/port.d root/response.d root/rmem.d
root/rootobject.d root/speller.d root/stringtable.d newdelete.o glue.a
backend.a
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum
deployment target of OS X 10.9
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum
deployment target of OS X 10.9
Undefined symbols for architecture x86_64:
  "symboldata(unsigned long long, unsigned int)", referenced from:
  el_ptr(Symbol*) in backend.a(el.o)
  el_convstring(elem*) in backend.a(el.o)
  out_readonly_sym(unsigned int, void*, int) in backend.a(out.o)
  Obj::sym_cdata(unsigned int, char*, int) in backend.a(machobj.o)
  "_align(unsigned long long, unsigned long long)", referenced from:
  codgen() in backend.a(cgcod.o)
  stackoffsets(int) in backend.a(cgcod.o)
  outjmptab(block*) in backend.a(cod3.o)
  outswitab(block*) in backend.a(cod3.o)
  type_paramsize(TYPE*) in backend.a(type.o)
  alignOffset(int, unsigned long long) in backend.a(out.o)
  cdfunc(elem*, unsigned int*) in backend.a(cod1.o)
  ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--- errorlevel 1
make: *** [dmd] Error 1
digger: Not caching dmd build failure due to temporary/environment error.
object.Exception@ae/sys/d/manager.d(756): Command ["make", "-f", "posix.mak",
"MODEL=64",
"HOST_DC=/Users/timothee/.config/digger/dl/dmd-2.067.1/dmd2/osx/bin/dmd"]
failed with status 2

```

--

[Issue 16595] New: thisExePath resolves symlinks but this isn't mentioned in docs

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16595

  Issue ID: 16595
   Summary: thisExePath resolves symlinks but this isn't mentioned
in docs
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

```
import std.file;
import std.stdio;
void main(){
  writeln(thisExePath);
}
```

```
cd /tmp/
rdmd -oftest main.d
ln -s ./test ./test_foo
./test_foo
/tmp/test
```

expected result:
/tmp/test_foo

Workaround?

--

[Issue 16580] [REG 2.072.0-b1] spawnShell segfaults on macOS

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16580

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull
 CC||c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
https://github.com/dlang/phobos/pull/4839

--

[Issue 16594] module destructors called again if an exception got thrown earlier

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16594

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Martin Nowak  ---
https://github.com/dlang/druntime/pull/1665

--

[Issue 16571] Unittests should not list /tmp/ recursively

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16571

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

   What|Removed |Added

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

--

[Issue 16571] Unittests should not list /tmp/ recursively

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16571

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

https://github.com/dlang/phobos/commit/b4061155cd667f31b2f7d42ea4ca8c2463f9665b
Fix Issue 16571 - Unittests should not list /tmp/ recursively

https://github.com/dlang/phobos/commit/08c587ead2156c85c30a2bbc18028b5967010682
Merge pull request #4838 from joakim-noah/temp

Fix Issue 16571 - Unittests should not list /tmp/ recursively

--

[Issue 16594] New: module destructors called again if an exception got thrown earlier

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16594

  Issue ID: 16594
   Summary: module destructors called again if an exception got
thrown earlier
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import core.stdc.stdio;

__gshared int count;

shared static ~this()
{
printf("dtor call %d\n", ++count);
if (count == 1) throw new Exception("dtor exception");
}
CODE
dmd -main -run bug

object.Exception@bug.d(8): dtor exception

??:? void bug._sharedStaticDtor1() [0x42792a]
??:? void bug.__modshareddtor() [0x427940]
??:? void
rt.minfo.__T17runModuleFuncsRevS442rt5minfo11ModuleGroup8runDtorsMFZ9__lambda1Z.runModuleFuncsRev(const(immutable(object.ModuleInfo)*)[])
[0x42db3e]
??:? void rt.minfo.ModuleGroup.runDtors() [0x42d5ac]
??:? int rt.minfo.rt_moduleDtor().__foreachbody1(ref
rt.sections_elf_shared.DSO) [0x42d8f3]
??:? int rt.sections_elf_shared.DSO.opApplyReverse(scope int delegate(ref
rt.sections_elf_shared.DSO)) [0x42dcee]
??:? rt_moduleDtor [0x42d8d2]
??:? rt_term [0x42b27e]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x427fc8]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x427f48]
??:? _d_run_main [0x427eb9]
??:? main [0x427a4d]
??:? __libc_start_main [0xf6eef730]
dtor call 1
dtor call 2


--

[Issue 16265] batter detection of real module cycles

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16265

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
Summary|unittest imports should not |batter detection of real
   |be counted as dependencies  |module cycles
   |for static ctors|

--- Comment #2 from Martin Nowak  ---
> unittest {
>import other; // other imports this module, and contains static ctors
>other.foo();
> }
> 
> Should not be considered a cycle. The shared ctor cannot possibly call the
> unit test code, so there is no leaking of the import.

Well, unfortunately it's technically possible using `__traits(getUnitTests,
__MODULE__)`, 
and it wouldn't be too far-fetched to call the tests from a static ctor.
The example is pretty close to do that
http://dlang.org/spec/traits.html#getUnitTests.

--

[Issue 16593] Building "tools" produces deprecation warnings

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16593

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull
 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/dlang/tools/pull/201

--

[Issue 16536] DMD master does not build on OS X 10.11.6/Xcode 7.3.1

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16536

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #7 from Martin Nowak  ---
Well, from the error message, it seems to me we're using `unsigned long long`
on the C side (typedef unsigned long long targ_ullong), but `unsigned long` on
the D side (alias targ_ullong = ulong).

(In reply to Jacob Carlborg from comment #6)

> I manually patch the compiler by replacing targ_size_t with size_t/d_size_t
> where the linker complains. I could create a PR but I don't know if it's the
> correct solution.

Well we want to always use unsigned long long on both sides (and for 32 and
64-bit dmds), b/c it must be able to hold any target's size_t (hence the name
targ_size_t).
It's a slightly different problem than the  fix for Issue 16000
https://github.com/dlang/dmd/pull/5788/files#diff-5910c4bad5eadf90caa32a46ab678aa0R12,
where we wanted size_t (4/8 bytes depending on 32/64-bit dmd) on both sides.

Not too sure, but I guess if you `typedef unsigned long targ_ullong` on OSX/64
it should work, but that stuff starts to become really messy.

--

[Issue 16593] New: Building "tools" produces deprecation warnings

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16593

  Issue ID: 16593
   Summary: Building "tools" produces deprecation warnings
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Obviously, we need to build warning-free.

--

[Issue 16592] New: Building dlang.org does not work without a preexisting dmd installation

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16592

  Issue ID: 16592
   Summary: Building dlang.org does not work without a preexisting
dmd installation
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

I've went through the following steps with a colleague:

1. Clone and build dmd using AUTO_BOOTSTRAP=1
2. Clone and build druntime
3. Clone, build, and unittest phobos
4. Clone and build tools
5. Clone and attempt to build dlang.org

At the last step the build didn't work. Building only the html,
druntime-prerelease, and phobos-prerelease did work.

We need to make sure the whole toolchain works without assuming/requiring a
preexisting dmd installation.

--

[Issue 16591] New: Spawn process on windows fails for npm start

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16591

  Issue ID: 16591
   Summary: Spawn process on windows fails for npm start
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

Following example is working fine on linux but on windows spawn process fails
with an exception. 

I have following folder structure:
./app.d
./js/helloworld.js
./js/package.json

content of helloworld.js:
console.log('hello world');

content of package.json:
{
  "name": "test",
  "version": "1.0.0",
  "scripts": {
"start": "node helloworld.js"
  }
}

content of app.d
import std.process, std.path, std.file, std.stdio;

void main()
{
  string workDir = buildPath(thisExePath.dirName, "js");
  string[] args = ["npm", "start"];
  spawnProcess(args, std.stdio.stdin, std.stdio.stdout, std.stdio.stderr, null,
std.process.Config.none, workDir);
}

I compile with dmd and then start the application.
On windows spawn process is not able to execute > npm start.
On Ubuntu Linux the application works fine.

To install node on ubuntu:
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs

For windows there is setup routine available on nodejs.org

--

[Issue 16587] split("", "x") should be []

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16587

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #3 from Andrei Alexandrescu  ---
Thanks, Vladimir!

--

[Issue 15735] std.algorithm.iteration.splitter returns empty range

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15735

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||and...@erdani.com
 Resolution|FIXED   |---

--- Comment #4 from Andrei Alexandrescu  ---
I'm reopening this pending a change in the documentation.

--

[Issue 16590] New: Wrong di generation for ref methods

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16590

  Issue ID: 16590
   Summary: Wrong di generation for ref methods
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sato...@rikarin.org

Hello,
I tried to create a static lib from phobos and druntime then generate header
files but I found some problems with it.

-H is stripping bodies from ref functions so return type cannot be deduced.
same for ref return functions.

exmaple from phobos/std/typecons.d
@property ref return T refCountedPayload();

--

[Issue 16589] Taking address of stack variables in @safe code is allowed in some cases

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16589

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

--

[Issue 16589] Taking address of stack variables in @safe code is allowed in some cases

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16589

Walter Bright  changed:

   What|Removed |Added

   Keywords||accepts-invalid, safe

--

[Issue 16589] New: Taking address of stack variables in @safe code is allowed in some cases

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16589

  Issue ID: 16589
   Summary: Taking address of stack variables in @safe code is
allowed in some cases
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Each of the return statements should all generate an error:

struct S
{
int data;

@safe int* access1()
{
return 
}

@safe S* access2()
{
return 
}
}

@safe int* access3(ref S s)
{
return 
}

@safe S* access4(ref S s)
{
return 
}

@safe int* access5(S s)
{
return 
}

@safe S* access6(S s)
{
return 
}

--

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

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #26 from Илья Ярошенко  ---
Probably related issue
http://forum.dlang.org/post/igqwbqawrtxnigplg...@forum.dlang.org

--

[Issue 14885] ideas for prettier and more useful backtraces

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #9 from Martin Nowak  ---
One idea would be to use an abbreviation scheme for template parameters,
similar to how we want to abbreviate the mangling.
https://issues.dlang.org/show_bug.cgi?id=15831#c13

Another pragmatic approach is to just show the FQN, but no template parameters.
Might lack some important information, but with the upper stacktrace parts
leading to the template, things should be clear most of the time.

--

[Issue 15831] IFTI voldemort type exploding bloat

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15831

--- Comment #15 from Martin Nowak  ---
(In reply to anonymous4 from comment #14)
> For stack trace it should be enough (for this example) mymodule.s.Result.foo
> without parameters even, file and line number should be enough to locate it.

Let's continue that part of the discussion in issue 14885.
We really just need someone to spec a feasible implementation.

--

[Issue 16536] DMD master does not build on OS X 10.11.6/Xcode 7.3.1

2016-10-04 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16536

--- Comment #6 from Jacob Carlborg  ---
I manually patch the compiler by replacing targ_size_t with size_t/d_size_t
where the linker complains. I could create a PR but I don't know if it's the
correct solution.

--