[Issue 14610] New: 'null this' assertion missing in 2.067
https://issues.dlang.org/show_bug.cgi?id=14610
Issue ID: 14610
Summary: 'null this' assertion missing in 2.067
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: tomerfil...@gmail.com
Consider the following code:
==
struct S {
void foo() {}
}
void main() {
S* s = null;
s.foo();
}
==
It used to crash with null this, e.g.,
core.exception.AssertError@main.d(2): null this
but as of 2.067 it crashes with
core.exception.AssertError@source/main.d(0): Assertion failure
So first of all, the message is undescriptive, and second, the line number is
0, which is very weird.
--
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak c...@dawg.eu --- How ludicrous to have a known race condition in synchronized and not fixing it for 3 years. --
[Issue 14607] dmd crashes intermittently when building in 32 bit mode
https://issues.dlang.org/show_bug.cgi?id=14607 --- Comment #3 from Sobirari Muhomori dfj1es...@sneakemail.com --- https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/affix_allocator.d - maybe this? --
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/0b41a6205361382930272813a5f6a2baae0c456a cleanup and rewrite rt.critical_ - reuse mutex declarations from rt.monitor_ - fix race condition (incorrect double checked locking) - modernize code for readability - use shared(D_CRITICAL_SECTION)* when dealing with unsynchronized data - replace STI/STD style C constructors - fix Issue 6607 - hopefully fix Issue 14584 - spurious autotester deadlocks --
[Issue 14611] New: socket.localAddress fails on Unix Sockets with longer Path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611
Issue ID: 14611
Summary: socket.localAddress fails on Unix Sockets with longer
Path ( 13 characters)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: dragosc...@gmail.com
import std.file;
import std.stdio;
import std.socket;
void main()
{
string unixSocketNameOk = 1234567890123;
auto sOk = new Socket(AddressFamily.UNIX, SocketType.STREAM);
sOk.bind(new UnixAddress(unixSocketNameOk));
scope (exit) remove(unixSocketNameOk);
writeln(sOk.localAddress);
string unixSocketNameFail = 12345678901234;
auto sFail = new Socket(AddressFamily.UNIX, SocketType.STREAM);
sFail.bind(new UnixAddress(unixSocketNameFail));
scope (exit) remove(unixSocketNameFail);
writeln(sFail.localAddress);
}
Output:
localhost:1234567890123
std.socket.SocketParameterException@std/socket.d(2894): Not enough socket
address storage
--
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 --- Comment #9 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/d50aba0083b03659f60c3f157a674d9846d8228f fix Issue 14573 - classes without destructor leak monitor/mutex - set finalize bit when constructing the monitor --
[Issue 14611] socket.localAddress fails on Unix sockets with longer path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611 Dragos Carp dragosc...@gmail.com changed: What|Removed |Added Summary|socket.localAddress fails |socket.localAddress fails |on Unix Sockets with longer |on Unix sockets with longer |Path ( 13 characters) |path ( 13 characters) --
[Issue 14611] socket.localAddress fails on Unix Sockets with longer Path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611 Dragos Carp dragosc...@gmail.com changed: What|Removed |Added Severity|enhancement |normal --
[Issue 14612] New: typeid(interface) returns TypeInfo_Class object
https://issues.dlang.org/show_bug.cgi?id=14612
Issue ID: 14612
Summary: typeid(interface) returns TypeInfo_Class object
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
In the following test code, typeid(i) does not return typeid(J) typed
TypeInfo_Interface, rather it returns typeid(J).info that is TypeInfo_Class.
import std.stdio;
interface I {}
interface J : I {}
class C : J {}
class D : C {}
void main()
{
D d = new D();
Object o = cast(Object)d;
I i = cast(I)d;
writeln(typeid(d) is typeid(D));// true
writeln(typeid(o) is typeid(D));// true
writeln(typeid(i) is typeid(I));// false ?
writeln(typeid(i) is typeid(J));// false ?
writeln(typeid(i) is typeid(D));// false ?
writeln(typeid(i)); // prints 'test.J' !?
// old exp.classinfo property is same with typeid(exp)
writeln(d.classinfo is typeid(D)); // true
writeln(o.classinfo is typeid(D)); // true
writeln(i.classinfo is typeid(J)); // false, same with typeid()
writeln(i.classinfo is typeid(I)); // false, same with typeid()
writeln(i.classinfo is typeid(D)); // false, same with typeid()
writeln( typeid(i) is typeid(J).info); // true
writeln(i.classinfo is typeid(J).info); // true
}
This nonintuitive behavior comes historically from D1.
In D1, ClassInfo, TypeInfo_Class, and TypeInfo_Interface are different classes.
In there, ClassInfo
had had the information of class *and* interface definition in runtime, and two
TypeInfo-s were purely
identity objects that associated with the class/interface types.
In D2, ClassInfo and TypeInfo_Class were merged into one (by issue 3380 ?).
Now ClassInfo is an alias name of TypeInfo_Class.
But, the separation between ClassInfo and TypeInfo_Interface is still there.
And currently, typeid(i) is completely same with i.classinfo, therefore it
still returns ClassInfo == TypeInfo_Class.
-
I think there's two ways to fix the behavior.
1. To make TypeInfo_Interface accessible from runtime interface references. To
do that,
change object.Interface struct as follows:
struct Interface
{
version(none) // old
{
TypeInfo_Class classinfo;
}
else // new
{
TypeInfo_Interface tinfo;
@property TypeInfo_Class classinfo() { return tinfo.info; }
}
void*[] vtbl;
size_t offset;
}
and then the interface vtb[0] will be the runtime TypeInfo_Interface that we
needing.
Pros: We need very little compiler and druntime changes.
Cons: It would add a small runtime cost in the dynamic cast.
See: druntime/src/rt/cast_.d
2. Separate ClassInfo from TypeInfo_Class again and define TypeInfo hierarchy
as follows:
abstract class ClassInfo : TypeInfo { ... }
class TypeInfo_Class : ClassInfo { ... }
class TypeInfo_Interface : ClassInfo { ... }
Pros: By handling ClassInfo, the runtime cost in dynamic cast operation can be
kept same with today's.
Cons: If an user still using the name 'ClassInfo', the code behavior will be
changed.
--
[Issue 14609] [REG2.068a] Github HEAD: DMD assertion failure for valid code
https://issues.dlang.org/show_bug.cgi?id=14609 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6e0a27b19219d1c2cd02fb3319d3e3a9bfabfcd7 fix Issue 14609 - Github HEAD: DMD assertion failure for valid code https://github.com/D-Programming-Language/dmd/commit/ba848af87cbba093ba9947e27090b9ef220f0334 Merge pull request #4672 from 9rnsr/fix14609 [REG2.068a] Issue 14609 - Github HEAD: DMD assertion failure for valid code --
[Issue 11738] partialShuffle actually shuffles the entire input
https://issues.dlang.org/show_bug.cgi?id=11738 --- Comment #4 from Ivan Kazmenko ga...@mail.ru --- (In reply to Joseph Rushton Wakeling from comment #3) (In reply to Ivan Kazmenko from comment #2) Disclaimer: I may have misunderstood the issue, in which case, please explain what is the intent here. At first glance, I reckon it's my screw-up misinterpreting the documentation. Sorry about that. :-( I'm not sure how much time I have in the near future, but I don't object to the original patch being reverted. I can submit a PR for that ~tomorrow if you want, seems trivial: change one line of actual code and a few unittests. --
[Issue 11738] partialShuffle actually shuffles the entire input
https://issues.dlang.org/show_bug.cgi?id=11738 --- Comment #3 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net --- (In reply to Ivan Kazmenko from comment #2) Disclaimer: I may have misunderstood the issue, in which case, please explain what is the intent here. At first glance, I reckon it's my screw-up misinterpreting the documentation. Sorry about that. :-( I'm not sure how much time I have in the near future, but I don't object to the original patch being reverted. --
[Issue 11738] partialShuffle actually shuffles the entire input
https://issues.dlang.org/show_bug.cgi?id=11738 --- Comment #5 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net --- (In reply to Ivan Kazmenko from comment #4) I can submit a PR for that ~tomorrow if you want, seems trivial: change one line of actual code and a few unittests. Sounds great, thank you :-) --
[Issue 7044] Missing a way to control the order of arguments passed to the linker makes impossible to link some programs
https://issues.dlang.org/show_bug.cgi?id=7044 --- Comment #39 from Walter Bright bugzi...@digitalmars.com --- Here's my evil plan: Add a switch -confsection=sectionname which will cause [sectionname] in the config file to be parsed. There can be multiple such switches and sections, they'll be parsed in lexical order. Note that: DFLAGS += string can be handled without adding new features with: DFLAGS = %DFLAGS% string The current way the config file is read twice wreaks havoc with the order in which sections are processed and things like appending to existing environment variables. This all has to be redone, but I'd like a green light on it being an acceptable resolution of this bugzilla issue before investing the effort. (Currently order of evaluation is undocumented.) I decided not to have -version=identifier do this, because inevitably someone will have a problem with it and want another switch to be able to do them independently. Calling it -confsection will place it next to the -conf switch in the documentation, making the connection easily discoverable. --
[Issue 14609] Github HEAD: DMD assertion failure for valid code
https://issues.dlang.org/show_bug.cgi?id=14609 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4672 --
[Issue 14609] [REG2.068a] Github HEAD: DMD assertion failure for valid code
https://issues.dlang.org/show_bug.cgi?id=14609 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Summary|Github HEAD: DMD assertion |[REG2.068a] Github HEAD: |failure for valid code |DMD assertion failure for ||valid code --
