[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #9 from Jacob Carlborg d...@me.com 2010-04-11 03:56:04 PDT --- Another question: since you have moved the module initialization into a new file and let every binary take care of its own initialization, couldn't that cause problems like circular dependencies that aren't detected? For example, two modules from two different libraries, each compiled into its own dll, which import the other module. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4064] [CTFE] array.reverse doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=4064 --- Comment #2 from bearophile_h...@eml.cc 2010-04-11 04:31:42 PDT --- Thank you for the comments. A third (c) possibility is to change the way CTFE is done, avoiding some duplication in the compiler. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4077] Bugs caused by bitwise operator precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4077 --- Comment #4 from bearophile_h...@eml.cc 2010-04-11 04:34:32 PDT --- Thank you for your comments. Requiring parentheses is one of the few solutions I can see. * (this is he only time I can recall being bitten by this in all my years of writing C and friends, so it really isn't a big deal to me) My experience shows that it's easy to forget bugs, because they are seen as something negative, so I suggest you to write them down :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4080] New: Patch for building dynamic libraries on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=4080 Summary: Patch for building dynamic libraries on Mac OS X Product: D Version: future Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg d...@me.com 2010-04-11 05:48:49 PDT --- Created an attachment (id=606) Adds the -dylib flag These three patches adds support for building dynamic libraries on Mac OS X. The patch for DMD adds the -dylib flag to the compiler. Building with this flag enabled will produce a dynamic library. The patch for druntime makes the necessary changes to build dynamic libraries. The D main function is now weakly linked, all of the module constructors of all the loaded images (executables, dynamic libraries) are run. The C main function is slightly modified to use the rt_init and rt_term functions. Two C functions are also added the will initialize and terminate the runtime if no D main function is available, i.e. a D plugin linked with a C application. The patch for phobos is just some modifications to the make file. To build druntime and phobos as dynamic libraries add dynamic, i.e. make -f osx.mak dynamic. A note about dynamic libraries on Mac OS X: Every dynamic library has an install name on Mac OS X which is the path to where an executable should look for the library when loading it. The build script sets this to @rpath/libname.dylib, where libname is libdruntime or libphobos2. @rpath is a relative path which the user can set when compiling an executable like this: dmd -L-rpath -L/path/to/library/. When the executable then is loaded it will search for the library in /path/to/library/libname.dylib. -rpath can be set multiple times. The user can also change the install name with the tool install_name_tool without needing to recompile. A change to the dmd.conf file is also needed. With this change the user doesn't have to set the @rpath every time when compiling. libdruntime must also be linked. dflags=...@p%/../src/phobos -...@p%/../src/druntime/import -l...@p%/../lib -L-rpath -...@p%/../lib -...@p%/../lib/libdruntime.dylib -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4080] Patch for building dynamic libraries on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=4080 --- Comment #1 from Jacob Carlborg d...@me.com 2010-04-11 05:49:32 PDT --- Created an attachment (id=607) Adds support for building dynamic libraries -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4080] Patch for building dynamic libraries on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=4080 --- Comment #3 from Jacob Carlborg d...@me.com 2010-04-11 05:52:34 PDT --- BTW the make files probably needs some cleaning up, make files are not my strong side. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3863] Various errors and ICE(todt.c) for struct constructors with ellipses
http://d.puremagic.com/issues/show_bug.cgi?id=3863
--- Comment #3 from S�nke Ludwig lud...@informatik.uni-luebeck.de 2010-04-11
07:53:32 PDT ---
I looked again at the assertion failure and it seems as it has had nothing to
do with the ellipses. Also does not occur on 2.043 anymore (but does on 2.041).
Reduced repro case:
---
struct Vec{
float member[2];
enum Vec constant = Vec(1, 2);
this(float a, float b){}
}
struct Test {
Vec member;
static immutable Test constant1 = Test(Vec(1, 2));
}
---
I could not find an existing bug report for the error messages more
initializers than fields or void initializer has no value. It seems that
when using type inference for the enum constant, the order of declarations of
the member variable, the enum constant and the constructor determines what
Vec(1, 2) means (struct literal or constructor call) or sees. But maybe it
would be better to make a seperate bug report and consider only the compiler
crash here?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4070] prefix const on member functions considered confusing
http://d.puremagic.com/issues/show_bug.cgi?id=4070 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2010-04-11 09:02:16 PDT --- Thinking some more about this I can add: A possible piece of the Zen of D language: Special cases in the language are bad, but sometimes they can be acceptable if they turn a consistent behaviour that can lead to mistakes/bugs into a good compile-time error. An example of this is disallowing: for(int i;i10;i++); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3863] Various errors and ICE(todt.c) for struct constructors with ellipses
http://d.puremagic.com/issues/show_bug.cgi?id=3863 --- Comment #4 from Don clugd...@yahoo.com.au 2010-04-11 11:32:54 PDT --- (In reply to comment #3) I looked again at the assertion failure and it seems as it has had nothing to do with the ellipses. Also does not occur on 2.043 anymore (but does on 2.041). Great! I can reproduce that, too. I could not find an existing bug report for the error messages more initializers than fields or void initializer has no value. It seems that when using type inference for the enum constant, the order of declarations of the member variable, the enum constant and the constructor determines what Vec(1, 2) means (struct literal or constructor call) or sees. But maybe it would be better to make a seperate bug report and consider only the compiler crash here? Yes, please make a separate bug. I'm pretty sure that the crash has a cause which is different from the rest. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3863] Various errors and ICE(todt.c) for struct constructors with ellipses
http://d.puremagic.com/issues/show_bug.cgi?id=3863
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords|rejects-valid |patch, wrong-code
--- Comment #5 from Don clugd...@yahoo.com.au 2010-04-11 14:51:25 PDT ---
Actually this is a rare case where the ICE bug is the same as the others.
I don't think it has anything to do with constructor varargs, actually.
It involves using a struct constructor to perform type inference of a member of
that struct.
Here's an example of a situation where the current behaviour leads to wrong
code:
struct Vec {
int w;
this(int x) { w = 2; }
enum KK = Vec(100);
enum Vec KK2 = Vec(100);
}
static assert(Vec.KK == Vec.KK2);
// Error: static assert ((Vec(100)) == (Vec(2))) is false
=
PATCH. Issue an error message in these potentially recursive situations.
Although in this specific case, it could be made to compile by running semantic
on the constructors first, that won't work in general (the constructor may make
use of the enum, for example).
I've tested this on the DMD test suite, and it passes.
expression.c CallExp::semantic(), line 6790.
==
#if !STRUCTTHISREF
/* Constructors return a pointer to the instance
*/
e = new PtrExp(loc, e);
#endif
e = e-semantic(sc);
return e;
}
+// Check for a forward reference to a struct constructor.
+else if (arguments arguments-dim !ad-ctor ad-sizeok !=
1)
+{
+// The semantic pass of the struct isn't yet complete.
+// Check for attempt to use a constructor.
+Dsymbol *ctor = ad-search(0, Id::ctor, 0);
+if (ctor)
+{
+error(Forward reference to struct constructor);
+return new ErrorExp();
+}
+}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: Missing trailing } still compiles under DMD1.057
Continued: Please be aware that the last } of function testFoo was missing. It compiled pretty good by bud -O -release -cleanup uniword.d
