[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)
https://issues.dlang.org/show_bug.cgi?id=14251 --- Comment #20 from Andrei Alexandrescu --- (In reply to Martin Nowak from comment #17) > Not allowing to put any class into read-only segments, just b/c someone > might want to synchronize on it, is not very convincing. > Also remember that we wanted to get rid of the extra 8-byte for monitor > unless explicitly requested > http://forum.dlang.org/post/xpliectmvwrwthamq...@forum.dlang.org. Fair enough. --
[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)
https://issues.dlang.org/show_bug.cgi?id=14251 --- Comment #19 from Andrei Alexandrescu --- (In reply to Martin Nowak from comment #18) > (In reply to Andrei Alexandrescu from comment #13) > > Can someone produce an example in which invariants promised by D's system > > are broken? > > Just look at core.sync, none of the methods can be implemented const or > pure, still they get called from const/pure code. That's not a problem, the runtime is expected to contain nonportable code. --
[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)
https://issues.dlang.org/show_bug.cgi?id=14251 --- Comment #18 from Martin Nowak --- (In reply to Andrei Alexandrescu from comment #13) > Can someone produce an example in which invariants promised by D's system > are broken? Just look at core.sync, none of the methods can be implemented const or pure, still they get called from const/pure code. In fact Object.Monitor simply declares that lock/unlock doesn't need to have any attributes https://github.com/dlang/druntime/blob/e9c7878928330aa34e6ba5c5863ed5507e02248e/src/object.d#L97-L101, but synchronized forges guarantees that aren't there. --
[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)
https://issues.dlang.org/show_bug.cgi?id=14251 --- Comment #17 from Martin Nowak --- (In reply to Andrei Alexandrescu from comment #15) > That's not the case. The compiler knows the object has mutable metadata and > won't allow placing it in read-only pages. Not allowing to put any class into read-only segments, just b/c someone might want to synchronize on it, is not very convincing. Also remember that we wanted to get rid of the extra 8-byte for monitor unless explicitly requested http://forum.dlang.org/post/xpliectmvwrwthamq...@forum.dlang.org. Turning synchronized into a lowering for lock/unlock (with monitor support as fallback) would not only allow correct attribute inference (w/o making global decisions for everyone, @nogc, ...), it's also a less overhead for the core.sync classes to not go through the virtual monitor indirections [¹]. [¹]: https://github.com/dlang/druntime/blob/15a227477a344583c4748d95492703901417f4f8/src/rt/monitor_.d#L59 --
[Issue 16515] Linker Error When Using -debug
https://issues.dlang.org/show_bug.cgi?id=16515 --- Comment #1 from gyroh...@gmail.com --- The linker being for "test.v.init", it seems it is trying to create "test.q.init" but can't as it can't find the symbol for "test.v.init". Though it shouldn't be constructing "test.q.init" anywhere, removing "-debug" from the compiler option fixes the issue. --
[Issue 16516] New: Linker Error for ModuleInfo
https://issues.dlang.org/show_bug.cgi?id=16516 Issue ID: 16516 Summary: Linker Error for ModuleInfo Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: gyroh...@gmail.com Created attachment 1615 --> https://issues.dlang.org/attachment.cgi?id=1615&action=edit attached file Not exactly sure why this is being caused, but I don't think it should be a linker problem. I get this linker error: Error 42: Symbol Undefined _D4test6second1t12__ModuleInfoZ I've tried to narrow it down as much as possible. Removing any import from any file in import/source/test/ seems to fix the issue. --
[Issue 16423] ModuleInfo missing when linking to static lib with classes
https://issues.dlang.org/show_bug.cgi?id=16423 --- Comment #4 from Martin Nowak --- Another rather obvious solution is to tell the linker to include the whole archive, sensibly named --whole-archive/--no-whole-archive for ld. Unfortunately dmd currently reorders linker flags (see issue 15574), so the following doesn't work. -L--whole-archive mystaticlib.a -L--no-whole-archive Instead you'll have to invoke cc for linking yourself atm. --
[Issue 16515] New: Linker Error When Using -debug
https://issues.dlang.org/show_bug.cgi?id=16515
Issue ID: 16515
Summary: Linker Error When Using -debug
Product: D
Version: D2
Hardware: All
URL: http://dlang.org/
OS: All
Status: NEW
Severity: enhancement
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: gyroh...@gmail.com
Created attachment 1614
--> https://issues.dlang.org/attachment.cgi?id=1614&action=edit
proj
I get a linker error for "test.v" even though "test.q" is never used. If you
remove the "test.v" member from "test.q" then the linker error no longer
happens.
struct Q(_T)
{
V!(1, _T) v; // removing this fixes link error
}
--
[Issue 16423] ModuleInfo missing when linking to static lib with classes
https://issues.dlang.org/show_bug.cgi?id=16423 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution|--- |WONTFIX --- Comment #3 from Martin Nowak --- It goes against the intention of static libraries to drag unused classes and module into a binary, and that also goes against our permanent fight against giant binaries. In fact there is issue 14555 and a PR (https://github.com/dlang/dmd/pull/4638) in the adverse direction. If you really want to drag in all classes from a static library, one approach is to reference all of them from a common module. Having an explicit list of all classes kind of contradicts the purpose of Object.factory, but I don't see how we can easily achieve both. Another approach is to generate object files for each module and explicitly link against all of them (the linker won't discard object files). Dub supports this as --build-mode=singleFile IIRC. Yet another approach is to use shared libraries instead. --
[Issue 16514] std.socket methods are const, and thus cannot be overriden for SSLSocket, for example
https://issues.dlang.org/show_bug.cgi?id=16514 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 16514] New: std.socket methods are const, and thus cannot be overriden for SSLSocket, for example
https://issues.dlang.org/show_bug.cgi?id=16514 Issue ID: 16514 Summary: std.socket methods are const, and thus cannot be overriden for SSLSocket, for example Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: ket...@ketmar.no-ip.org commit 1fc5f9b34ca9bb333ee429ab2ca39e07c3304f01 made most of virtual methods of std.socket `const`, and now it is not possible to do any internal housekeeping in overriden methods. bind, connect, listen, accept... this should be reverted. --
[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling
https://issues.dlang.org/show_bug.cgi?id=16513 --- Comment #4 from Martin Nowak --- (In reply to uplink.coder from comment #2) > Hash collisions will happen! > We need a way to speed up those equals compares in rootObject. > I'll look if I can find a good way to gradually remove the virtual calls. This whole RootObject hashing/comparison is a kludge when we can cheaply generate a unique string. > IsVariable!(Simulated_Object_966) > IsMemberVariable!(Simulated_Object_975) > isSomeFunction!(Simulated_Object_573) > > Those SHOULD produce the same hash they work on the same types! Yes right, only the arguments are part of the hash. > I am of the impression that template-inlining can help here. True for isSomeFunction and it does work, the other 2 take alias parameters (via variadic arguments) and create one instance per object (w/ the same hash). --
[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling
https://issues.dlang.org/show_bug.cgi?id=16513 --- Comment #3 from Martin Nowak --- Managed to speed up the test case from 1.8s to 1.2s, almost completely eliminating the lookup cost. Still need to fix a few issues, the cppmangler thinks member variables are static, we might not want to fill the idPool with unused identifiers (would save some memory to just compute the hash), needs some more testing whether the mangling is really bijective, if so we could only hash the string and ditch the TemplateInstance.compare code. --
[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling
https://issues.dlang.org/show_bug.cgi?id=16513 --- Comment #2 from uplink.co...@googlemail.com --- Hash collisions will happen! We need a way to speed up those equals compares in rootObject. I'll look if I can find a good way to gradually remove the virtual calls. IsVariable!(Simulated_Object_966) IsMemberVariable!(Simulated_Object_975) isSomeFunction!(Simulated_Object_573) Those SHOULD produce the same hash they work on the same types! I am of the impression that template-inlining can help here. --
[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling
https://issues.dlang.org/show_bug.cgi?id=16513 Martin Nowak changed: What|Removed |Added CC||goober...@gmail.com, ||uplink.co...@googlemail.com --- Comment #1 from Martin Nowak --- It's the horrible hash that is causing the performance issue. Arguments as widely different than genericIndexOf!(CPPMethods, ushort, int, uint, long, ulong) genericIndexOf!(VTable, ushort, int, uint, long, ulong) produce the same hash. >From the 88.3K lookups, 7900 have the hash 1 (one). The test code that triggered the issue contains 1K instances of VariableDescriptor!(tonsofsimulatedobjects, SimulatedEntity, "Simulated_Object_1063") VariableDescriptor!(tonsofsimulatedobjects, SimulatedEntity, "Simulated_Object_1064") and lots of instances like IsVariable!(Simulated_Object_963) IsMemberVariable!(Simulated_Object_973) isSomeFunction!(Simulated_Object_571) IsVariable!(Simulated_Object_964) IsMemberVariable!(Simulated_Object_974) isSomeFunction!(Simulated_Object_572) IsVariable!(Simulated_Object_966) IsMemberVariable!(Simulated_Object_975) isSomeFunction!(Simulated_Object_573) all producing the same hash. With such a crappy hash the behavior degrades back to the old linear search. I'll try to replace this with the mangling suffix (.getIdent) instead which should be both simpler and effective, given that all mangling bugs are fixed. --
