[Issue 6204] New: emplace() for classes accepts larger chunk but fails in array assignment
http://d.puremagic.com/issues/show_bug.cgi?id=6204
Summary: emplace() for classes accepts larger chunk but fails
in array assignment
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: acehr...@yahoo.com
--- Comment #0 from Ali Cehreli acehr...@yahoo.com 2011-06-24 00:20:13 PDT ---
This is tested with dmd 2.053 release version.
In the class version of emplace(), the following enforce indicates that it is
legal to have a chunk larger than the instance size:
enforce(chunk.length = __traits(classInstanceSize, T),
new ConvException(emplace: chunk size too small));
Unfortunately, the following array assignment fails when that's the case:
// Initialize the object in its pre-ctor state
(cast(byte[]) chunk)[] = typeid(T).init[];
Here is a program that reproduces the issue:
import std.conv;
class C
{
int i;
}
size_t alignedSize(T)()
{
return (__traits(classInstanceSize, T) + T.alignof - 1)
/ T.alignof * T.alignof;
}
void main()
{
enum roomPerObject = alignedSize!C();
ubyte[roomPerObject] buffer;
void[] placeForObject = (buffer.ptr)[0..roomPerObject];
emplace!C(placeForObject);
}
The last line throws at runtime:
object.Exception@src/rt/arraycat.d(31): lengths don't match for array copy
A proposed fix would be to assign only to the first part of the chunk:
(cast(byte[]) chunk)[0..__traits(classInstanceSize, T)] = typeid(T).init[];
(Note the range on the left hand side of the assignment.)
That gets rid of the problem but I am not sure about what to do with the
potentially-non-zero remaining bytes of the chunk. The caller may assume that
they will be cleared by emplace().
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6205] New: Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205
Summary: Strongly-pure nothrow functions with ignored return
value are entirely stripped even if it contains a
failing 'assert'.
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2011-06-24 01:05:51 PDT ---
Test case:
---
int x() pure nothrow {
assert(false, 1);
}
void main() {
x();
}
---
This should throw an AssertError, but instead the generated program does
nothing. The AssertError will be thrown if the return value of 'x' is assigned
to some variable though.
This bug (?) causes 'runnable/test41.d' to fail since commit 4c9661f as nothrow
inference is also implemented, making 'imports.test41a.func' a strongly-pure
nothrow function, and the 'assert' inside fails to run.
https://github.com/D-Programming-Language/dmd/commit/4c9661fa9fbd427909a334133dfc7f3869e47c31
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-06-24 01:29:19 PDT --- I'm not sure that this is a bug. It's a strongly pure function. It _is_ nothrow, which means that it won't throw any Exception, and its return value isn't used. assert is more of a debugging tool than anything. Sure, assert(false) sticks around in release mode, but still. Based on the purity and nothrow rules, this function can be optimized out of existance. I really don't see a problem with this. Now, assuming that is indeed the correct behavior, the obviously runnable/test41.d needs to be fixed, but it looks to me like having the call to x optimized out of existance makes perfect sense. And if the assert doesn't get hit, then it doesn't get hit. Asserts are intended primarily for debugging purposes. Yes, it's an assert(false) and not a normal assert, but still, if we start worrying about whether an assert would have killed a function or not, then we won't be able to optimize out functions like this, which wouldn't be good IMHO. Now, assuming that it's really only an issue when you have a strongly pure function where you throw away its return value, then maybe that's not a big deal, because that's bad code on the part of the programmer anyway, but I'm still inclined to think that it makes sense for x to never be called in this code (at least if optimizations are turned on). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5676] [CTFE] segfault using tuple containing struct that has opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=5676
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Summary|Evaluating nested |[CTFE] segfault using tuple
|std.typecons.tuple calls at |containing struct that has
|compile time crashes DMD|opAssign
OS/Version|Mac OS X|All
--- Comment #1 from Don clugd...@yahoo.com.au 2011-06-24 01:56:04 PDT ---
Reduced test case. It happens with compile time assignment to a tuple which
contains an object with an opAssign. Not a regression, failed in 2.040 as well.
struct S5676
{
int x;
void opAssign(S5676 rhs) { x = rhs.x;}
}
struct Tup5676(E...)
{
E g;
void foo(E values) { g = values; }
}
bool ice5676()
{
Tup5676!(S5676) q;
q.foo( S5676(3) );
assert( q.g[0].x == 3); // crashes here
return true;
}
static assert(ice5676());
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 --- Comment #2 from kenn...@gmail.com 2011-06-24 02:06:12 PDT --- Pull request for test41 if this is considered INVALID: https://github.com/D-Programming-Language/dmd/pull/162 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6206] New: Pure function not called in comma expression in for loop increment
http://d.puremagic.com/issues/show_bug.cgi?id=6206
Summary: Pure function not called in comma expression in for
loop increment
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-06-24
02:21:32 PDT ---
Test case:
struct S
{
int i = 0;
void incr() pure { ++i; }
}
void main()
{
S s;
for (int j=0; j10; s.incr(), ++j) { }
assert (s.i == 10); // fails
}
The assert should pass, but it fails iff S.incr() is marked as pure. (In fact,
S.i is never increased at all in this case.) Note that moving '++j' into the
loop body makes the bug disappear. It seems the call to s.incr() must be part
of a comma expression for the bug to manifest.
While seemingly obscure, this has some very real consequences. For example, it
means std.algorithm.equal() doesn't work with ranges that have a pure
popFront().
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6206] Pure function not called in comma expression in for loop increment
http://d.puremagic.com/issues/show_bug.cgi?id=6206 kenn...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||kenn...@gmail.com Resolution||DUPLICATE --- Comment #1 from kenn...@gmail.com 2011-06-24 02:28:28 PDT --- Exactly the same as bug 5798, which turns out not completely fixed. *** This issue has been marked as a duplicate of issue 5798 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5798] Weakly pure function calls skipped inside a comma expression
http://d.puremagic.com/issues/show_bug.cgi?id=5798 kenn...@gmail.com changed: What|Removed |Added CC||bugzi...@kyllingen.net --- Comment #6 from kenn...@gmail.com 2011-06-24 02:28:28 PDT --- *** Issue 6206 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5798] Weakly pure function calls skipped inside a comma expression
http://d.puremagic.com/issues/show_bug.cgi?id=5798 kenn...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from kenn...@gmail.com 2011-06-24 02:26:41 PDT --- I thought this in a 'for' loop (comment 3) has been fixed, but it doesn't. Re-opening. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don clugd...@yahoo.com.au 2011-06-24 02:30:58 PDT --- The bug is that the compiler's behaviour isn't consistent. It's reasonable to optimize the function away in this case -- but then, it should generate an 'expression has no effect' warning. See bug 3882. This test case is an excellent justification for treating 3882 as a bug, rather than an enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5798] Weakly pure function calls skipped inside a comma expression
http://d.puremagic.com/issues/show_bug.cgi?id=5798
--- Comment #7 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-06-24
02:39:10 PDT ---
Adding my test case from issue 6206 here, since it's much smaller and doesn't
pull in any Phobos modules.
struct S
{
int i = 0;
void incr() pure { ++i; }
}
void main()
{
S s;
for (int j=0; j10; s.incr(), ++j) { }
assert (s.i == 10); // fails
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6207] New: Mixin template evaluated to string can convert to string mixin expression implicitly
http://d.puremagic.com/issues/show_bug.cgi?id=6207
Summary: Mixin template evaluated to string can convert to
string mixin expression implicitly
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-06-24 03:48:28 PDT ---
If mixin template instantiation makes manifest constant string and it appears
in expression context, the compiler converts it implicitly to string mixin
expression.
This enhancement feature does not conflict with any existing features.
Because normal instantiating with mixin template is illegal.
Sample code:
mixin template expand(string code)
{
static if (code.length = 2 code[0..2] == $x)
{
enum expand = `x` ~ code[2..$];
pragma(msg, expand);
}
else
enum expand = code;
}
void main()
{
int x = 1;
int y = expand!q{$x+2};
// Rhs is implicitly converted to mixin(expand!(q{$x+2}))
assert(y == 3);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6194] [GSoC] Destructor gets called on object before it is copied when calling writeln()
http://d.puremagic.com/issues/show_bug.cgi?id=6194
--- Comment #3 from Cristi Cobzarenco cristi.cobzare...@gmail.com 2011-06-24
04:23:28 PDT ---
(In reply to comment #2)
I'm not sure if it's a bug in DMD or Phobos. I'm inclined to it's Phobos bug.
The loop variable 'a' in the reduced 'formattedWrite' is obviously escaping
its
scope, so calling the destructor is reasonable. However, this is essentially
the implementation of std.format.formattedWrite:
1. the arguments are taken address
foreach (i, arg; args)
{
funs[i] = formatGeneric!(Writer, typeof(arg), Char);
// We can safely cast away shared because all data is either
// immutable or completely owned by this function.
argsAddresses[i] = cast(const(void*)) arg;
}
2. and then they are referred later for actual formatting.
{
funs[currentArg](w, argsAddresses[currentArg], spec);
++currentArg;
}
https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L302
This works for me:
foreach (i, arg; args)
{
funs[i] = formatGeneric!(Writer, typeof(arg), Char);
static if(hasAliasing!(typeof(arg)))
{
-argsAddresses[i] = arg;
+argsAddresses[i] = args[i];
}
else
{
// We can safely cast away shared because all data is either
// immutable or completely owned by this function.
-argsAddresses[i] = cast(const(void*)) arg;
+argsAddresses[i] = cast(const(void*)) args[i];
}
}
Unfortunately we can't replace the foreach with a for loop because we can't do
typeof( args[ i ] ). Does any one have any idea how we could avoid copying the
arguments needlessly?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6201] [GSoC] Ref Non-Ref overloading doesn't work on structs.
http://d.puremagic.com/issues/show_bug.cgi?id=6201 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||k.hara...@gmail.com Resolution||DUPLICATE --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-06-24 04:48:56 PDT --- *** This issue has been marked as a duplicate of issue 4843 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4843] Inconsistency in overloading ref vs. non-ref
http://d.puremagic.com/issues/show_bug.cgi?id=4843 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||cristi.cobzare...@gmail.com --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-06-24 04:48:56 PDT --- *** Issue 6201 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889 --- Comment #4 from Kenji Hara k.hara...@gmail.com 2011-06-24 04:52:32 PDT --- bug4843 (and its duplication bug6201) is part of this issue. FuncDeclaration::overloadResolve use TypeStruct::defaultInit, but it makes lvalue. So ref and non-ref overloads make ambiguous. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4843] Inconsistency in overloading ref vs. non-ref
http://d.puremagic.com/issues/show_bug.cgi?id=4843 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||k.hara...@gmail.com Depends on||5889 --- Comment #2 from Kenji Hara k.hara...@gmail.com 2011-06-24 04:54:00 PDT --- This issue is part of bug5889. Add 'Depends on'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6208] New: Parameter storage classes are ignored in template function deducing.
http://d.puremagic.com/issues/show_bug.cgi?id=6208
Summary: Parameter storage classes are ignored in template
function deducing.
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-06-24 09:00:09 PDT ---
In the following code, ref storage class of function foo's parameter s is
ignored.
So calling foo with lvalue makes confusing.
int foo(S)(ref S s){ return 1; }
int foo(S)(S s){ return 2; }
void main()
{
int n;
assert(foo(n) == 1); // Line 6
assert(foo(0) == 2);
}
test.d(6): Error: template test.foo(S) foo(S) matches more than one template
declaration, test.d(1):foo(S) and test.d(2):foo(S)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6208] Parameter storage classes are ignored in template function deducing.
http://d.puremagic.com/issues/show_bug.cgi?id=6208 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-06-24 09:01:35 PDT --- P.S. Same problem exists with out and lazy. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6019] Phobos imports in autogenerated .di header files break implicit linking with DLLs
http://d.puremagic.com/issues/show_bug.cgi?id=6019 --- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-06-24 10:37:27 PDT --- It seems another workaround for this is to create a dummy symbol in the module that imports a header file, e.g.: extern(C) int D3dll5mydll12__ModuleInfoZ; // implicitly adds _ before the name This fixes linker errors. However it has to be put in the module that imports dll.mydll, and not inside dll.mydll module itself as that creates some kind of symbol clashes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6209] New: -L\implib and -H generation should follow -od flag
http://d.puremagic.com/issues/show_bug.cgi?id=6209 Summary: -L\implib and -H generation should follow -od flag 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-06-24 11:00:56 PDT --- Currently calling -H to generate header files and -L\implib to create import libraries via the linker creates .di and .lib files in the current directory, regardless if the -od switch is present. This makes it difficult to make build scripts which must keep their current working directory intact in order to resolve imports, but where the output files need to be in some subdirectory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4282] Problem in AAs with fixed size arrays as keys
http://d.puremagic.com/issues/show_bug.cgi?id=4282 kenn...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||kenn...@gmail.com Resolution||FIXED --- Comment #1 from kenn...@gmail.com 2011-06-24 13:22:46 PDT --- (In reply to comment #0) (Similar traps are very bad in a language. In this situation I suggest to produce a compile-time error, or better to convert the slice into the correct 2 char array to be used as key). DMD now errors with Error: cannot implicitly convert expression (txt[i..i + 2u]) of type char[] to char[2u] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5007] @outer() attribute
http://d.puremagic.com/issues/show_bug.cgi?id=5007 --- Comment #3 from bearophile_h...@eml.cc 2011-06-24 17:16:06 PDT --- See for more comments: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=139389 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5607] Slow small integer division
http://d.puremagic.com/issues/show_bug.cgi?id=5607 --- Comment #1 from bearophile_h...@eml.cc 2011-06-24 18:24:48 PDT --- See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=139394 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6211] New: __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211
Summary: __traits (compile) return wrong result when the bug
happen
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: l...@galador.net
--- Comment #0 from Lloyd Dupont l...@galador.net 2011-06-24 18:30:57 PDT ---
I'm using DMD2.053 on Windows7 x64
My test case:
- I have a all in one console application which output true true
- I have a project with the exact same code split into a static lib and an
exe and it output false false
The bug is that the output is different!
=== first the all in one, outputing true, true =
module main;
import std.variant;
import std.stdio;
import std.metastrings : Format;
import std.traits;
public mixin template property(T, string name)
{
mixin(Format!(private T _%s;
@property public T %s() { return _%s; }
@property public void %s(T value) { _%s = value; }, name,
name, name, name, name));
}
interface IInter
{
}
class Foo : IInter
{
static this()
{
Compiled!(Foo, FP);
Compiled!(Foo, Subfoo);
}
@property public Foo FP() { return new Foo(); }
@property public void FP(Foo f) { }
mixin property!(Foo, Subfoo);
}
int main(string[] argv)
{
return 0;
}
void Compiled(T, string memberName)()
{
T t;
writeln(mixin( __traits(compiles, t. ~memberName ~ = (
~typeof(__traits(getMember, T, memberName)).stringof ~).init) ));
}
==
now the splitted program, outputting false, false
whereas it should output true, true just like above, shouldn't it!?!
= lib.d
module lib;
import std.variant;
import std.stdio;
import std.metastrings : Format;
import std.traits;
public mixin template property(T, string name)
{
mixin(Format!(private T _%s;
@property public T %s() { return _%s; }
@property public void %s(T value) { _%s = value; }, name,
name, name, name, name));
}
interface IInter
{
}
void Compiled(T, string memberName)()
{
T t;
writeln(mixin( __traits(compiles, t. ~memberName ~ =
~typeof(__traits(getMember, T, memberName)).stringof ~).init ));
}
== main.d =
module main;
import lib;
class Foo : IInter
{
static this()
{
Compiled!(Foo, FP);
Compiled!(Foo, Subfoo);
}
@property public Foo FP() { return new Foo(); }
@property public void FP(Foo f) { }
mixin property!(Foo, Subfoo);
}
int main(string[] argv)
{
return 0;
}
= buildrun.bat =
dmd -lib -g -debug -X -oflib1.lib lib.d
dmd -g -debug -X main.d lib1.lib
main
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6211] __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution||INVALID --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com 2011-06-24 18:38:13 PDT --- This is not a bug. See section Instantiation Scope of http://www.d-programming-language.org/template.html . TemplateInstantances are always performed in the scope of where the TemplateDeclaration is declared, with the addition of the template parameters being declared as aliases for their deduced types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6211] __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211
--- Comment #2 from Lloyd Dupont l...@galador.net 2011-06-24 19:03:57 PDT ---
How does the template scope has anything to do with this bug?
In plain English I'm testing that the property can be set.
I.e.
class Foo
{
@property public Foo Subfoo() {}
@property public Foo Subfoo2() {}
@property public void Subfoo2(Foo f) {}
}
in the above class Subfoo can't be set, Subfoo2 can.
I'm testing it with
Foo f,
__traits(compile, f.Suboo = Foo.init)
__traits(compile, f.Suboo2 = Foo.init)
This seems to work erratically!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6211] __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211 --- Comment #3 from Lloyd Dupont l...@galador.net 2011-06-24 20:24:36 PDT --- Not understanding the explanation I can't claim it wrong... Nonetheless the work around I found seems to indicate to me that the explanation was, at the very least (for what I understand) completely irrelevant. I replaced: writeln(mixin( __traits(compiles, t. ~memberName ~ = (~typeof(__traits(getMember, T, memberName)).stringof ~).init) )); With: writeln(mixin( __traits(compiles, t. ~memberName ~ = (typeof(t.~memberName ~)).init) )); And it worked. Still using library and exe. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6211] __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2011-06-24 20:29:43 PDT --- Sorry, it looked like you were instantiating a template in a scope where a symbol passed by name as a string didn't exist. You may want to reduce your example to the smallest amount of code which illustrates the bug for clarity. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6211] __traits (compile) return wrong result when the bug happen
http://d.puremagic.com/issues/show_bug.cgi?id=6211
--- Comment #5 from Lloyd Dupont l...@galador.net 2011-06-24 21:01:19 PDT ---
I found a way to reduce the sample even further.
1st no need to have 2 project (lib exe). All in the same exe (but different
module) is enough to cause the bug.
main.d
module main;
import lib;
class Foo
{
static this()
{
Compiled!(Foo, Subfoo);
}
@property public Foo Subfoo() { return null; }
@property public void Subfoo(Foo f) { }
}
int main(string[] argv)
{
return 0;
}
== lib.d ==
module lib;
import std.traits;
import std.stdio;
void Compiled(T, string memberName)()
{
T t;
writeln(mixin( __traits(compiles, t. ~memberName ~ = (
~typeof(__traits(getMember, T, memberName)).stringof ~).init) ));
}
===
this output false, whereas it should output true
a work around (and simpler code in fact) is to use the following simpler mixin
(in Compiled)
---
writeln(mixin( __traits(compiles, t. ~memberName ~ = (typeof(t. ~memberName
~)).init) ));
---
Yet I do think this sample highlight a compiler bug
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
