[Issue 5281] Equality among arrays of Bigints
http://d.puremagic.com/issues/show_bug.cgi?id=5281
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch, wrong-code
CC||clugd...@yahoo.com.au
Depends on||3659
Severity|normal |critical
--- Comment #2 from Don clugd...@yahoo.com.au 2010-12-01 23:56:02 PST ---
This is difficult. The patch (below) fixes the problem, and I believe it's
correct. The problem is, that applying it causes Phobos to break, because it
has
been relying on this bug. And I don't know how to modify Phobos to fix it.
Specifically, Tuple and Variant are affected.
There's a cluster of bugs related to the problem, eg: bug 3659 (Too much
exegesis on opEquals, bug 3607 Problems with struct opEquals and const).
But the major problem is that with a const ref signature, opEquals cannot
perform comparisons with rvalues. So the code below fails
struct Foo
{
bool opEquals(ref const Foo f) const { return true; }
}
Foo foo()
{
Foo result;
return result;
}
void main()
{
Foo f;
//assert(f == foo()); // does not compile
}
--
To make this patch work with the existing Phobos, while bug 3659 is not fixed,
change
if (!eq)
fdx-error(type signature should be %s not %s
into
if (!eq !td)
fdx-error(type signature should be %s not %s
PATCH:
StructDeclaration::semantic in struct.c
Around line 503,
tfeqptr = new TypeFunction(parameters, Type::tbool, 0, LINKd);
tfeqptr-mod = MODconst;
tfeqptr = (TypeFunction *)tfeqptr-semantic(0, sc2);
Dsymbol *s = search_function(this, Id::eq);
FuncDeclaration *fdx = s ? s-isFuncDeclaration() : NULL;
+TemplateDeclaration *td = s ? s-isTemplateDeclaration() : NULL;
+if (td)
+{
+Expressions arguments;
+arguments.setDim(1);
+arguments.data[0] = (void*) param;
+fdx = td-deduceFunctionTemplate(sc, loc, NULL, NULL, arguments,
1);
+}
if (fdx)
{
eq = fdx-overloadExactMatch(tfeqptr);
if (!eq)
fdx-error(type signature should be %s not %s,
tfeqptr-toChars(), fdx-type-toChars());
}
-TemplateDeclaration *td = s ? s-isTemplateDeclaration() : NULL;
-// BUG: should also check that td is a function template, not just a
template
-if (!eq !td)
+if (!eq)
eq = buildOpEquals(sc2);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5286] To avoid a problem with Template syntax
http://d.puremagic.com/issues/show_bug.cgi?id=5286 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #6 from Don clugd...@yahoo.com.au 2010-12-02 01:01:19 PST --- This bug report is actually asking for the non-parentheses template instantiation to be discarded entirely. It is a feature which relies 100% on the precedence rules. Remember that templates can have value parameters, so even something like: int y; auto x = to!Foo(y); can be considered to be ambiguous. Is it: to!(Foo)(y) or to!(Foo(y)) This applies to ALL function templates. The idea that there are a few ambiguous cases which could generate errors, is completely wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5264] x86_64 changes for druntime 2
http://d.puremagic.com/issues/show_bug.cgi?id=5264 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Attachment #830 is|0 |1 obsolete|| --- Comment #6 from Brad Roberts bra...@puremagic.com 2010-12-02 02:53:29 PST --- Created an attachment (id=835) remaining changes to pass semantic checks of druntime (actually not all, see also bug 5263 for intrinsic cleanup) This time I ran the druntime and phobos unittests on 32 bit. They pass. The 64 bit tests can't be run yet as there's still dmd codgen bugs while building druntime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5281] Equality among arrays of Bigints
http://d.puremagic.com/issues/show_bug.cgi?id=5281 --- Comment #3 from bearophile_h...@eml.cc 2010-12-02 04:45:44 PST --- (In reply to comment #2) The problem is, that applying it causes Phobos to break, because it has been relying on this bug. If this this true then this bug gains higher priority. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5309] New: Add language support for external D symbols refs
http://d.puremagic.com/issues/show_bug.cgi?id=5309
Summary: Add language support for external D symbols refs
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ah0801...@yahoo.com
--- Comment #0 from Austin Hastings ah0801...@yahoo.com 2010-12-02 05:01:21
PST ---
Presently there is no way that I can find to declare a D symbol in another
module. That is, this doesn't work:
==
module m1;
import some.type; // defines SomeType
extern(D) SomeType m2.var;
void foo()
{
m2.var.doSomething();
}
==
The reason I want this is that I am generating D source code programmatically -
a file full of tables. And I am using DMD's dependency reporting facility to
generate build rules for use in a Makefile.
Because of the build rules, all of the source code has to be valid enough to
satisfy DMD at all times. Including when the generated code files do not exist
(after a make clean, for example).
That means that I cannot have an import of a file which does not exist, so I
cannot simply do import generated.module;
D *does* have support for extern (C), and I could certainly use that. But that
eliminates the benefit of namespacing in the first place.
What I would like is a way to provide a module definition that includes the
declaration of an external D object. This way my code could import that module
definition, and the build system would be happy. And the generated code could
be generated, compiled, and added to the library later on, and the whole thing
would work together and sing Kumbaya and live in peace and harmony, modulo the
occasional lion attack.
Frustratingly, DMD already HAS this: the .di file. So that's what I'm using. It
works pretty much exactly the way I want, except of course that I'm not
generating the .di file from the .d source (which is itself a generated file).
Sadly, though, the spec says
(http://www.digitalmars.com/d/2.0/dmd-linux.html#interface_files):
D interface files bear some analogous similarities to C++ header files. But
they are not required in the way that C++ header files are, and they are not
part of the D language. They are a feature of the compiler, and serve only as
an optimization of the build process.
The important part being they are not part of the D language.
I'm sure that I'm not the first, or even the second, person to think of
generating data tables in source files. So I'm requesting either (1) what is
the part-of-the-D-language way to do this; or (2) please add the .di mechanism,
or something very much like it, to the D language proper.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4172] Improve varargs
http://d.puremagic.com/issues/show_bug.cgi?id=4172 --- Comment #15 from Fawzi Mohamed fa...@gmx.ch 2010-12-02 05:51:36 PST --- To keep backward compatibility and a working D1 compiler at least for D1, if marshalling is too difficult with the current compiler I would evaluate the effort of creating a hidden variadic template function for each variadic function, that (using a tuple) would pass the stuff following the old convention to the real variadic function defined as taking void*,TypeInfo[]. Then at each calling point after the overload resolution, if the match is for the variadic function one would call the corresponding variadic template function. As the differences between variadic functions and template functions are just small overloading differences (maybe not any more in D2, I did not check the details), and the possibility to override variadic functions, and those would still work correctly, with such an approach one can keep D1 working also on 64 bit architectures. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5302] Inline assembler: Indexing struct fields not possible inside member function
http://d.puremagic.com/issues/show_bug.cgi?id=5302 --- Comment #2 from Harry Vennik htven...@zonnet.nl 2010-12-02 07:52:48 PST --- Created an attachment (id=836) Failing code -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5302] Inline assembler: Indexing struct fields not possible inside member function
http://d.puremagic.com/issues/show_bug.cgi?id=5302 --- Comment #3 from Harry Vennik htven...@zonnet.nl 2010-12-02 07:55:26 PST --- (From update of attachment 836) Compiling this results in the following error message: iasm_test.d(15): Error: this for i needs to be type S not type iasm_test.A iasm_test.d(15): bad type/size of operands '(__error).i' -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5308] std.conv should also use a to function to convert to other class types
http://d.puremagic.com/issues/show_bug.cgi?id=5308 Jesse Phillips jesse.k.phillip...@gmail.com changed: What|Removed |Added Component|websites|Phobos Summary|std.conv documentation is |std.conv should also use a |behind implementation |to function to convert to ||other class types Severity|normal |enhancement --- Comment #1 from Jesse Phillips jesse.k.phillip...@gmail.com 2010-12-02 09:19:25 PST --- Sorry, was testing it on classes, but the to function is used when it is not a class. So I have made it an enhancement request. And the request is either to allow it for classes also, or remove it for non-classes and use opCast instead. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3541] Add -oq to dmd (use fully qualified module name as object filename)
http://d.puremagic.com/issues/show_bug.cgi?id=3541 --- Comment #7 from nfx...@gmail.com 2010-12-02 09:28:19 PST --- I'm updating this patch to new dmd versions all the time, just mail me if you're actually interested in it lol. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4095] compiling with -op -od and using absolute paths for source files make dmd write object files anywhere
http://d.puremagic.com/issues/show_bug.cgi?id=4095 --- Comment #3 from nfx...@gmail.com 2010-12-02 09:43:39 PST --- As of dmd 1.065, the behaviour seems to be slightly different. Anyway, it still doesn't work. dmd keeps overwriting its own object files if there are modules with same name from different packages. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4095] compiling with -op -od and using absolute paths for source files make dmd write object files anywhere
http://d.puremagic.com/issues/show_bug.cgi?id=4095 --- Comment #4 from nfx...@gmail.com 2010-12-02 10:16:51 PST --- (In reply to comment #3) dmd keeps overwriting its own object files if there are modules with same name from different packages. Scratch that, up on closer inspection, the problem is exactly the same as described in the initial comment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5310] New: Variant == const(Variant) doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=5310
Summary: Variant == const(Variant) doesn't compile
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-12-02 13:23:11 PST ---
import std.variant;
void foo(const Variant a)
{
Variant b;
assert (a == b);
}
---
dmd test0
test0.d(12): Error: template std.variant.VariantN!(maxSize).VariantN.opEquals(T
) does not match any function template declaration
test0.d(12): Error: template std.variant.VariantN!(maxSize).VariantN.opEquals(T
) cannot deduce template function from argument types !()(VariantN!(maxSize))
And if you change the assert into: assert(b==a);
you get:
c:\dmd\windows\bin\..\..\src\phobos\std\variant.d(499): Error: static assert
A
ssigning Variant objects from const Variant objects is currently not
supported.
c:\dmd\windows\bin\..\..\src\phobos\std\variant.d(481):instantiated
from
here: opAssign!(const(VariantN!(maxSize)))
c:\dmd\windows\bin\..\..\src\phobos\std\variant.d(737):instantiated
from
here: __ctor!(const(VariantN!(maxSize)))
test0.d(12):instantiated from here: opEquals!(const(VariantN!(maxSize))
)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5051] dmd flag for partial compilation (similar to just running preprocessor in C/C++)
http://d.puremagic.com/issues/show_bug.cgi?id=5051 Trass3r mrmoc...@gmx.de changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #3 from Trass3r mrmoc...@gmx.de 2010-12-02 15:38:19 PST --- Yeah, post it, please. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4501] Can't call templated properties as properties from within class
http://d.puremagic.com/issues/show_bug.cgi?id=4501
Stanislav Blinov stanislav.bli...@gmail.com changed:
What|Removed |Added
CC||stanislav.bli...@gmail.com
Platform|Other |All
OS/Version|Windows |All
--- Comment #1 from Stanislav Blinov stanislav.bli...@gmail.com 2010-12-02
16:27:16 PST ---
This seems related, though error manifests outside of class body:
class Bar
{
@property T num(T = int)() const // Note default type
{
T result;
//...
return result;
}
}
void main()
{
auto bar = new Bar;
auto n1 = bar.num!int; // Ok
auto n2 = bar.num; // Error: Bar.num(T = int) has no value
auto n3 = bar.num!float; // Ok
}
I don't know if it's worth separate issue report.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
