[Issue 15189] Dwarf debug info is inaccurate
https://issues.dlang.org/show_bug.cgi?id=15189 Timothee Cour changed: What|Removed |Added CC||timothee.co...@gmail.com --- Comment #4 from Timothee Cour --- I was going to write a bug report regarding a similar issue I had and found this bug. Any update on that? My observations: * wrong line numbers (off by 1 or more) are shown when debugging with lldb and compiling with dmd -g * ldc doesn't have this issue --
[Issue 15747] New: debug info missing for static library (dmd only, ldc is ok)
https://issues.dlang.org/show_bug.cgi?id=15747 Issue ID: 15747 Summary: debug info missing for static library (dmd only, ldc is ok) 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 dmd -oflibfoo.a -lib -g foo.d dmd -ofmain -g -L-lfoo main.d When debugging main with lldb, debug info (eg line numbers) will appear only for symbols in main.d, not for those in the library foo.d ldc doesn't have this problem (whether using .a or .dyld) Also somewhat relevant: https://issues.dlang.org/show_bug.cgi?id=15189 [Dwarf debug info is inaccurate] --
[Issue 15748] New: inconsistent symbols generated by dmd vs ldc
https://issues.dlang.org/show_bug.cgi?id=15748
Issue ID: 15748
Summary: inconsistent symbols generated by dmd vs ldc
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: timothee.co...@gmail.com
test.d:
---
module tests.stacktrace.test2.test;
void test(){}
---
$compiler -oflibfoo.a -lib -g test.d
compiler=dmd:
nm libfoo.a|grep _D5tests10stacktrace5test24testFZv
warning: nm: no name list
02d4 S _D5tests10stacktrace5test24testFZv
compiler=ldmd2:
0240 T __D5tests10stacktrace5test24testFZv
several things differ:
double '_' for ldmd2, single for dmd
T (text section) for ldmd2 vs S for dmd
I was actually trying to link a program compiled with dmd with a library
compiled with ldc, and ran into:
Undefined symbols for architecture x86_64:
"_D5tests10stacktrace5test212__ModuleInfoZ", referenced from:
_D5tests10stacktrace4test12__ModuleInfoZ in z02.o
"_D5tests10stacktrace5test24testFZv", referenced from:
__Dmain in z02.o
Shouldn't this use case be supported ?
Even if not 100%; would enable use cases involving fast compile times from dmd
+ fast code (for critical code) from ldc.
--
[Issue 15721] free error when calling Mallocator.dispose on interfaces
https://issues.dlang.org/show_bug.cgi?id=15721 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15721] free error when calling Mallocator.dispose on interfaces
https://issues.dlang.org/show_bug.cgi?id=15721 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/211c10aff2b2cdfd9280f159cab7825b8a323c80 fixed issue 15721 https://github.com/D-Programming-Language/phobos/commit/e55e196127c75899a36016cba12b8cbd5c1548d9 Merge pull request #4022 from BBasile/issue-15721 fixed issue 15721 - std.experimental.allocator dispose on interface --
[Issue 15748] inconsistent symbols generated by dmd vs ldc
https://issues.dlang.org/show_bug.cgi?id=15748 --- Comment #1 from Sobirari Muhomori --- Single underscore is standard mangling for D symbols, most platforms take it literally, mac traditionally adds extra underscore to all symbols. --
[Issue 15749] New: allow `with` on an expression
https://issues.dlang.org/show_bug.cgi?id=15749
Issue ID: 15749
Summary: allow `with` on an expression
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: john.loughran.col...@gmail.com
The motivation is stuff like this:
zip(iota(10), iota(10, 20))
.map!(t => Tuple!(int, "a", int, "b)(t))
.map!(t => with(t) a + b);
which, short of having some proper tuple unpacking syntax (that would be so, so
good), is nicer than the current
.map!((t) { with(t) return a + b; });
that might seem like a small change, but I'm having a hard time selling D and
functional programming to scientists with all the heavyweight syntax, they are
spoiled by the inefficient but neat-looking numpy model.
--
[Issue 15750] New: net/isemail uses lots of redundant helper methods
https://issues.dlang.org/show_bug.cgi?id=15750 Issue ID: 15750 Summary: net/isemail uses lots of redundant helper methods 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 In my cleanup task I saw that std.net.isemail seems to do some redundant effort and defines those methods as its own helper: - substr - max - compareFirstN - grep - get There is `backPop`! All of these methods (at least max, substr) feel general purpose enough that they should existent in a general fashion. Btw for max: doesn't work get with ranges, but there is a pending pull request. https://github.com/D-Programming-Language/phobos/pull/4019 --
[Issue 15738] Problem with std.experimental.ndslice empty()
https://issues.dlang.org/show_bug.cgi?id=15738 Илья Ярошенко changed: What|Removed |Added CC||ilyayaroshe...@gmail.com --- Comment #1 from Илья Ярошенко --- This is feature, empty is empty!0, so it checks only first dimension. In addition, this is very important for optimization reasons. emptyAny method may be added for desirable behavior. --
[Issue 15738] Problem with std.experimental.ndslice empty()
https://issues.dlang.org/show_bug.cgi?id=15738 Илья Ярошенко changed: What|Removed |Added Hardware|x86_64 |All OS|Windows |All Severity|normal |enhancement --
[Issue 15751] New: atomicLoad doesn't return stable result if compiled with -profile
https://issues.dlang.org/show_bug.cgi?id=15751
Issue ID: 15751
Summary: atomicLoad doesn't return stable result if compiled
with -profile
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andrey.zheri...@gmail.com
atomicLoad() doesn't constantly return 0 in the following code if it's compiled
with -profile option:
=
import core.atomic;
int main()
{
shared int s = 0;
return atomicLoad(s);
}
=
Compiler: DMD32 D Compiler v2.070.2
Compile command: dmd test.d -oftest_p -profile
Test command:
pass=0; fail=0;
for i in $(seq 1 100);
do
./test_p.exe && pass=$((pass+1)) || fail=$((fail+1));
done;
echo pass=$pass fail=$fail
Test command output (example):
pass=89 fail=11
Even adding "atomicStore(s, 0);" right before atomicLoad doesn't guarantee the
result:
pass=95 fail=5
--
[Issue 15752] New: Diagnostic: Better Error Message for Assigning Incorrect AA Empty Value
https://issues.dlang.org/show_bug.cgi?id=15752
Issue ID: 15752
Summary: Diagnostic: Better Error Message for Assigning
Incorrect AA Empty Value
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: j...@jackstouffer.com
Because of the use of [] to enclose AA assignment, one could be forgiven in
accidentally doing something like this:
void main() {
int[int] a = [];
}
Which results in the very unhelpful message:
Error: can't have associative array key of void
Of course, the right answer is to use null, but again, the similarities with
array literals one could be expected to make this mistake. The error message is
also different when trying to do this for an optional function parameter.
void func(int[int] b = []) {
}
void main() {
func();
}
Error: cannot implicitly convert expression ([]) of type void[] to int[int]
The message should be something like this:
Error: can't have associative array key of void. Perhaps you meant to
initialize an empty AA with null?
--
[Issue 15752] Diagnostic: Better Error Message for Assigning Incorrect AA Empty Value
https://issues.dlang.org/show_bug.cgi?id=15752 Jack Stouffer changed: What|Removed |Added Keywords||diagnostic --
