[Issue 15760] Segfault when compiling when using __gshared and selective import.
https://issues.dlang.org/show_bug.cgi?id=15760 ag0ae...@gmail.com changed: What|Removed |Added Keywords||ice CC||ag0ae...@gmail.com --
[Issue 15765] New: TypeInfo for C++ classes uses wrong vtbl
https://issues.dlang.org/show_bug.cgi?id=15765
Issue ID: 15765
Summary: TypeInfo for C++ classes uses wrong vtbl
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
extern (C++) class RootObject
{
bool equals(RootObject o)
{
return o is this;
}
int compare(RootObject)
{
assert(0);
}
void print()
{
assert(0, "Should not get called");
}
}
void main()
{
bool[RootObject] aa;
aa[new RootObject] = true;
}
CODE
dmd -run bug
Because TypeInfo_Class casts every void* to a standard Object, it ends up
calling the wrong vtable entries for operations like getHash.
I think we need a dedicated TypeInfo_CppClass that is similar to
TypeInfo_Struct with it's xopEquals and xopHash in order to fix this bug.
C++ classes don't inherit from the common Object class, so those methods must
not exist.
--
[Issue 15766] New: extern(Objective-C) should result in compile error on OS X 32bit
https://issues.dlang.org/show_bug.cgi?id=15766 Issue ID: 15766 Summary: extern(Objective-C) should result in compile error on OS X 32bit Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: d...@me.com --
[Issue 143] 'package' does not work at all
https://issues.dlang.org/show_bug.cgi?id=143 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/431dd2028bb913db836cbc21d01989c19d5c363e fix Issue 143 --
[Issue 3254] [module] Module member visibility depends on declaration order
https://issues.dlang.org/show_bug.cgi?id=3254 --- Comment #8 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e527108f9153cedab2ca658d053b2ac81610e55d fix Issue 3254 - Module member visibility depends on declaration order --
[Issue 1754] module member visibility does not affect conflicts
https://issues.dlang.org/show_bug.cgi?id=1754 --- Comment #6 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/054db4feac43ca997b88a56f3aac0664b513cb5c fix issue 1754 --
[Issue 2991] [module] Import within aggregate causes conflicts with private identifiers
https://issues.dlang.org/show_bug.cgi?id=2991 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 1754] module member visibility does not affect conflicts
https://issues.dlang.org/show_bug.cgi?id=1754 github-bugzi...@puremagic.com changed: What|Removed |Added Resolution|DUPLICATE |FIXED --
[Issue 1238] Private identifiers in imported modules create conflicts with public ones
https://issues.dlang.org/show_bug.cgi?id=1238 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 2991] [module] Import within aggregate causes conflicts with private identifiers
https://issues.dlang.org/show_bug.cgi?id=2991 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2c371ceed6f17d58d67f2b1c34b175eec541e7f2 fix issue 2991 --
[Issue 3254] [module] Module member visibility depends on declaration order
https://issues.dlang.org/show_bug.cgi?id=3254 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues
https://issues.dlang.org/show_bug.cgi?id=340 Issue 340 depends on issue 3254, which changed state. Issue 3254 Summary: [module] Module member visibility depends on declaration order https://issues.dlang.org/show_bug.cgi?id=3254 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 143] 'package' does not work at all
https://issues.dlang.org/show_bug.cgi?id=143 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 10750] Strict aliasing semantics
https://issues.dlang.org/show_bug.cgi?id=10750 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 1238] Private identifiers in imported modules create conflicts with public ones
https://issues.dlang.org/show_bug.cgi?id=1238 --- Comment #13 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8839a6c8c24777b576e3594629804185cff21c0e fix issue 1238 --
[Issue 15738] Problem with std.experimental.ndslice empty()
https://issues.dlang.org/show_bug.cgi?id=15738 --- Comment #2 from bearophile_h...@eml.cc --- (In reply to Илья Ярошенко from comment #1) > 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. I think it's a trap. empty === enoty!0 is not explicit. So it should be designed the other way, in an explicit way. If you want to add a empty() method, it should work on the whole tensor. If you want to see if one coordinate is empty, you can add a more specialized method, like emptySide, or something similar. --
[Issue 15738] Problem with std.experimental.ndslice empty()
https://issues.dlang.org/show_bug.cgi?id=15738 --- Comment #3 from Илья Ярошенко --- (In reply to bearophile_hugs from comment #2) > (In reply to Илья Ярошенко from comment #1) > > 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. > > I think it's a trap. empty === enoty!0 is not explicit. So it should be > designed the other way, in an explicit way. If you want to add a empty() > method, it should work on the whole tensor. If you want to see if one > coordinate is empty, you can add a more specialized method, like emptySide, > or something similar. Slice is not a container, so there is no reason for such behavior. `empty` must be as fast as possible because a user may use slices with std.algorithm and std.range. --
[Issue 15767] New: Why isn't there a deprecation plan for TypeTuple?
https://issues.dlang.org/show_bug.cgi?id=15767 Issue ID: 15767 Summary: Why isn't there a deprecation plan for TypeTuple? 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 I read that TypeTuple is an alternate name for AliasSeq for legacy compatibility. https://github.com/D-Programming-Language/phobos/blob/master/std/typetuple.d If it's legacy, why is there no @deprecated and no deprecation plan for std.typetuple? --
[Issue 15768] New: std.stdio.trustedStdout accesses __gshared data without synchronization.
https://issues.dlang.org/show_bug.cgi?id=15768
Issue ID: 15768
Summary: std.stdio.trustedStdout accesses __gshared data
without synchronization.
Product: D
Version: D2
Hardware: All
URL: http://forum.dlang.org/post/vrchiulmsqxtdeadrrjo@forum
.dlang.org
OS: All
Status: NEW
Severity: major
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: marco.le...@gmx.de
std.stdio.trustedStdout returns a copy of stdout which invokes the postblit of
File. This is done without internal synchronization and so the reference count
increment/decrement is prone to race conditions if stdout has been assigned an
ordinary file. The following snippet is thus likely to close stdout too early,
resulting - for example - in segmentation faults inside Glibc:
stdout = File("/dev/null", "w");
foreach(t; 1000.iota.parallel)
writeln("Oops");
When Phobos is compiled with assertions, the bug is generally caught within the
File struct itself.
The compiler did warn that accessing the global data `stdout` would be unsafe
(because of potential race conditions). A wrapper `trustedStdout` was written
to make stdout usable in @safe code, but it bears no warning as to threading
issues.
Compare to: https://issues.dlang.org/show_bug.cgi?id=15645 where @trusted was
added to silence legitimate compiler warnings about safety, resulting in a
Phobos bug.
Ultimately I believe that stdout must be a shared resource with a shared
postblit and dtor that decrements the ref count in an atomic way or stdout must
not be reassignable at all. See also: The situation with thread-safety of
std.logger's global stdlog.
--
[Issue 15700] Source code links are partially broken
https://issues.dlang.org/show_bug.cgi?id=15700 greenify changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from greenify --- seems to be fixed with newer versions. --
[Issue 15769] New: Unittests example should have titles
https://issues.dlang.org/show_bug.cgi?id=15769 Issue ID: 15769 Summary: Unittests example should have titles 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 We see multiple Examples statement and the title of the snippet is display as a comment. e.g. http://dlang.org/phobos/std_algorithm_sorting.html#sort Examples: // Showcase stable sorting ... Examples: // Sorting floating-point numbers in presence of NaN ... Ideally I think we should 1) only show "Examples" once (easy) 2) get the title from the comment string above the unittest (maybe trickier) --
[Issue 15769] Unittests example should have titles
https://issues.dlang.org/show_bug.cgi?id=15769 greenify changed: What|Removed |Added Component|phobos |dlang.org --
[Issue 15770] New: SocketSet.add OutOfMemoryError on Posix
https://issues.dlang.org/show_bug.cgi?id=15770 Issue ID: 15770 Summary: SocketSet.add OutOfMemoryError on Posix Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: an...@s-e-a-p.de While adding a not alive socket to a SocketSet using method add() there is following error: ERR core.exception.OutOfMemoryError@src/core/exception.d(679): Memory allocation failed In some scenarios it is quite hard to find the root cause (not alive socket). An exception like InvalidSocket instead would be quite nice. Tested on linux. --
