[Issue 6014] New: rt_finalize Segmentation fault , dmd 2.053 on linux freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014 Summary: rt_finalize Segmentation fault , dmd 2.053 on linux freebsd Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: chang...@gmail.com --- Comment #0 from changlon chang...@gmail.com 2011-05-15 23:13:11 PDT --- I build my projects on linux64 freebsd32 . the same runtime error keep touble me . Program received signal SIGSEGV, Segmentation fault. 0x004ba73f in rt_finalize () . The dmd version is 2.053 release, I remove all dtor ~this() from my code but the error still exists. I have no idea how to reduce the example, I just sure the error is throw when i call Parse.parse . http://gool.googlecode.com/files/jade_dtor_bug.tar.bz2 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6015] New: [CTFE] Strange behavior of assignment appears in a situation
http://d.puremagic.com/issues/show_bug.cgi?id=6015
Summary: [CTFE] Strange behavior of assignment appears in a
situation
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: youx...@gmail.com
--- Comment #0 from Hisayuki Mima youx...@gmail.com 2011-05-16 00:45:47 PDT
---
struct Foo{
string field;
}
bool func(string input){
Foo foo;
foo.field = input[0..$];
assert(foo.field == test);
foo.field = test2;//assignment1
assert(foo.field == test);//assertion1
assert(foo.field == test2);//assertion2
return true;
}
static assert(func(test));
This code doesn't work on dmd v2.053.
Somehow assertion1 succeeds and somehow assertion2 fails in CTFE.
This shows that assignment1 has wrong behavior.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014 --- Comment #1 from changlon chang...@gmail.com 2011-05-16 02:21:42 PDT --- I notice that if throw exception in dtor will cause some problem , but in this case is no exception, and also no dtor exists . the package I post here dtor is still exists, you can remove them and test agian (util.pool.dtor, jade.Compiler.dtor). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6016] New: Struct named Object with class in one module
http://d.puremagic.com/issues/show_bug.cgi?id=6016
Summary: Struct named Object with class in one module
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: trivial
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: alienballa...@gmail.com
--- Comment #0 from Mariusz Gliwiński alienballa...@gmail.com 2011-05-16
04:21:13 PDT ---
Compiling
code
class a {}
struct Object {}
/code
results in:
Assertion failure: 'b-type-ty == Tclass' on line 464 in file 'class.c'
Some meaningful name about confusion with object.d would be nice
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6017] New: std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 Summary: std.algorithm.remove has a wrong link Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-16 07:47:06 PDT --- This: http://d-programming-language.org/phobos/std_algorithm.html#remove points to the enum EditOp; instead of the function remove(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #1 from kenn...@gmail.com 2011-05-16 08:19:59 PDT --- It's not technically wrong as the enum value's name is really 'EditOp.remove'... Perhaps those enum values shouldn't be linked. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 08:37:43 PDT --- The way that ddoc generates links needs to be completely rewritten. It needs to be hierarchal, but it's not at all. It acts like it's just linking in a set of free functions, and I believe that it links in the first symbol with a particular name, so if you have multiple documented symbols with the same name, then it's always the first one which gets linked in, regardless of whether that's the one which would be most usefully linked. I do think that having EditOp.remove linked is of value. But the links should be arranged in such a way that their hierarchy is clear, which would mean that the link would clearly be associated with EditOp and that the remove function would have its own link. I believe that this is really a fundamental ddoc problem and not a website problem at all. And I think that the table tha std.algorithm has now is as close to a fix as you're going to get any time soon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 10:29:58 PDT --- Wouldn't the problem be solved simpler by forcing it to generate unique anchor names for identifiers? I'm not sure how to understand Jonathan's comment about this, but I don't think DDoc actually thinks the two removes are the same identifier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5995] string append negative integer causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5995 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2011-05-16 10:31:52 PDT --- Hm... I think in general it is a design flaw to allow int to implicitly cast to dchar. I think that is the source of the problem. Going from (d|w)char to the appropriate width integer should be fine, but going the other way seems prone to error. Note that in lifetime.d, the assert(0) should not lead to a segmentation fault. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 10:39:26 PDT --- Ddoc always generates a link to the first identifier with a given name. How it does that, I don't know. But it makes no attempt to make the links represent any kind of hierarchy. They're purely based on the base names of identifiers and completely ignore whether a particular identifier is actually an enum value or a member of a class or struct. It's designed as if everything were a free function. The way that the links are generated is far too simplistic and needs to be redesigned. In this case, both an enum value and a function have the same name. The enum happens to be first on the page, so it gets the link. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6018] New: Multiple includes of std.parallelism causes DMD to segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=6018 Summary: Multiple includes of std.parallelism causes DMD to segfault. Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jcrapuchet...@gmail.com --- Comment #0 from Jonathan Crapuchettes jcrapuchet...@gmail.com 2011-05-16 10:42:54 PDT --- If a project includes several files and each has a private import of std.parallelism, DMD will segfault. If the imports are moved to a single public import, the compilation will finish correctly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 10:40:49 PDT --- My suggestion was to simply give one of them the anchor name remove_2, or something like that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5995] string append negative integer causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5995 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 10:44:52 PDT --- Implicitly converting to the same-size _unsigned_ integral type might be fine, but converting to a signed type would be a narrowing conversion. I'd still argue that converting between any of the character types and any of the integral types should require a cast though simply because they're not only different types, they're different types of types. The character types are for characters and the integral types are for integers. Regardless, no implicit conversion should be permitted when it's a narrowing conversion. Narrowing conversions should require casts. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 10:52:51 PDT --- They do need unique anchor names, but those anchor names should probably include the hiercharchy in some manner rather than simply having numbers tagged onto them - e.g. #EditOp__remove and #remove. The core problem is that ddoc doesn't care about anything other than the base identifier name. It makes no attempt to worry about the hiercharchy or about duplicate names. And honestly, it shouldn't have to worry about duplicate names, because duplicate names are illegal in the actual code. The duplication occurs because it's effectively treating all of the identifiers as if they were at module-level. Regardless, unique anchor names will be necessary. But I don't think that simply tacking on numbers is the right way to go about it. The fundamental problem needs to be solved. If you want to see a really bad example of the problem, looke at std.datetime. Several structs in there have the same function name, and the links become pretty useless. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #7 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 10:56:42 PDT --- Yeah, I never said that this is a GOOD solution, but it's a quick and dirty one, and it'll allow linking to stuff in StackOverflow answers until someone fixes it properly ;) Several structs in there have the same function name, and the links become pretty useless. Hmm, so what should be done about this? Serialize the function signature into the anchor name? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5995] string append negative integer causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5995
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #5 from timon.g...@gmx.ch 2011-05-16 11:01:47 PDT ---
(In reply to comment #3)
Hm... I think in general it is a design flaw to allow int to implicitly cast
to
dchar.
I think that is the source of the problem.
Going from (d|w)char to the appropriate width integer should be fine, but
going
the other way seems prone to error.
Note that in lifetime.d, the assert(0) should not lead to a segmentation
fault.
assert(0) emits asm{hlt;} when compiled in release mode. Encountering hlt _is_
a segmentation fault, so this is just fine.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5995] string append negative integer causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5995
--- Comment #6 from timon.g...@gmx.ch 2011-05-16 11:07:36 PDT ---
(In reply to comment #4)
Implicitly converting to the same-size _unsigned_ integral type might be fine,
but converting to a signed type would be a narrowing conversion. I'd still
argue that converting between any of the character types and any of the
integral types should require a cast though simply because they're not only
different types, they're different types of types. The character types are for
characters and the integral types are for integers. Regardless, no implicit
conversion should be permitted when it's a narrowing conversion. Narrowing
conversions should require casts.
How is that narrowing? No information is lost.
@Topic:
void main(){
uint i=-1; //fine
dchar c=-1; //compile time error
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #9 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 11:17:40 PDT --- __ makes some sense since it's unlikely to ever be the case that you'll end up with underscores at the beginning and/or end of identifiers such that You can put periods in anchor names (MediaWiki uses them to escape other characters, for example), so there's no need for underscores. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 11:24:05 PDT --- Ah. I didn't know that. I wrongly assumed that it wouldn't. That solves the problem quite nicely then. The obvious solution is then to represent the hiearchy directly. So, remove gets the anchor #EditOp.remove. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4957] std.concurrency does not allow to pass Tid in struct fields
http://d.puremagic.com/issues/show_bug.cgi?id=4957 Sean Kelly s...@invisibleduck.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||s...@invisibleduck.org --- Comment #2 from Sean Kelly s...@invisibleduck.org 2011-05-16 11:23:18 PDT --- Curses! Seems I'll have to apply 'shared' to private members of Tid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5995] string append negative integer causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5995
--- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2011-05-16
11:26:52 PDT ---
(In reply to comment #6)
void main(){
uint i=-1; //fine
dchar c=-1; //compile time error
}
Just tried this and it indeed produces an error:
Error: cannot implicitly convert expression (-1) of type int to dchar
So I wonder why this works? Seems inconsistent:
int i = -1;
dchar c = i;
Also, the reporter's issue seems to be inconsistent with that error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6019] New: Implicit linking with D DLLs doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=6019
Summary: Implicit linking with D DLLs doesn't work
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-16
16:02:19 PDT ---
Test case: http://dl.dropbox.com/u/9218759/dll_bug.zip
Use the build.bat file or issue these commands:
cd dll
dmd -H -of..\mydll.dll -L/IMPLIB mydll.d
cd..
dmd driver.d -I. dll\mydll.lib
The exported D function is found by the linker, and you can find the name in
the mydll.dll, mydll.lib, and driver.obj files, it has this name:
_D3dll5mydll3fooFiZi
However DMD also generates a mydll.obj file which references this symbol:
_D3dll5mydll12__ModuleInfoZ
This symbol isn't exported in the DLL and you won't find it in the import lib,
and hence the linker error.
Daniel Green made a comment from this thread
http://www.digitalmars.com/d/archives/digitalmars/D/learn/.di_header_imports_with_DLL_symbols_fails_to_link_25571.html:
Probably unrelated, but this same issue showed up in the GDC backend.
Apparently, the compiler tried to be smart about exporting ModuleInfo
only for those modules that needed it. The fix was to always export it
regardless.
Note that you cannot just pass a .di header file directly to DMD because DMD
will statically compile the mydll.foo function found in the header file, and
the application won't need the DLL anymore.
You also cannot prototype the foo() function directly in driver.d, because this
function will be mangled together with its module name (mangled mydll.driver vs
mangled driver.foo).
The alternative is manually figuring out the mangling of the function name and
using explicit linking via GetProcAddress friends.
---
One more thing: Apparently in v2.053 linking with core.dll_helper doesn't work
anymore:
import core.dll_helper;
void main() {}
Error 42: Symbol Undefined _D4core10dll_helper12__ModuleInfoZ
--- errorlevel 1
Is that a known issue? Linking with core.sys.windows.dll does work though.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6018] Multiple includes of std.parallelism causes DMD to segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=6018 David Simcha dsim...@yahoo.com changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #1 from David Simcha dsim...@yahoo.com 2011-05-16 17:28:57 PDT --- Can you elaborate a little? I haven't been seeing this. Specifically, have you been compiling all the files together or separately? Can you create a small test case? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4760] core.atomic.atomicLoad() should be public
http://d.puremagic.com/issues/show_bug.cgi?id=4760 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from David Simcha dsim...@yahoo.com 2011-05-16 17:29:26 PDT --- This was resolved in 2.053. No idea why it wasn't marked as such. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6020] New: Dead link: http://d-programming-language.org/32-64-portability.html
http://d.puremagic.com/issues/show_bug.cgi?id=6020 Summary: Dead link: http://d-programming-language.org/32-64-portability.ht ml Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-16 18:29:46 PDT --- Linked from http://d-programming-language.org/howtos.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6019] Implicit linking with D DLLs using import switch doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=6019 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-16 18:41:33 PDT --- Also the guide which shows how to write and use D DLLs using a similar technique and .def files exhibits the same problem (and it also imports the non-existent std.gc module): http://d-programming-language.org/dll.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6019] Implicit linking with D DLLs using import switch doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=6019
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-16
18:47:19 PDT ---
(In reply to comment #0)
One more thing: Apparently in v2.053 linking with core.dll_helper doesn't work
anymore:
import core.dll_helper;
void main() {}
Error 42: Symbol Undefined _D4core10dll_helper12__ModuleInfoZ
--- errorlevel 1
Is that a known issue? Linking with core.sys.windows.dll does work though.
Disregard that. It seems I've had this module leftover from 2.052. That should
teach me not to copy/paste new releases over old ones.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014 --- Comment #2 from changlon chang...@gmail.com 2011-05-16 18:48:44 PDT --- The same code work fine in Win32, the runtime rt_finalize error is since dmd 2.052. The Win32 dmd 2.052 has same problem , but fiexd in dmd 2.053 . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6021] New: std.parallelism missing from dpl.org
http://d.puremagic.com/issues/show_bug.cgi?id=6021 Summary: std.parallelism missing from dpl.org Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-16 21:04:33 PDT --- http://d-programming-language.org/phobos/index.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6023] New: std.random.uniform and std.bigint.BigInt compilation error
http://d.puremagic.com/issues/show_bug.cgi?id=6023
Summary: std.random.uniform and std.bigint.BigInt compilation
error
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dpx.infin...@gmail.com
--- Comment #0 from Vladimir Matveev dpx.infin...@gmail.com 2011-05-16
22:00:21 PDT ---
uniform function from standard library doesn't work correctly with standard
BigInt. There are no indications anywhere that it shouldn't work, so I think it
is a bug.
Code sample:
import std.stdio;
import std.bigint;
import std.random;
void main() {
BigInt x = uniform, BigInt(1000));
writefln(%s, x);
}
Compilation error:
/usr/include/d/dmd/phobos/std/conv.d(322): Error: function
std.bigint.BigInt.toString (void delegate(const(char)[]) sink, string
formatString) const is not callable using argument types ()
/usr/include/d/dmd/phobos/std/conv.d(322): Error: expected 2 function
arguments, not 0
Linux i686, dmd 2.052
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6003] BigInt length and conversion properties problems
http://d.puremagic.com/issues/show_bug.cgi?id=6003 Paul D. Anderson paul.d.ander...@comcast.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
