[Issue 4424] Copy constructor and templated opAssign cannot coexist
http://d.puremagic.com/issues/show_bug.cgi?id=4424
Benjamin Thaut c...@benjamin-thaut.de changed:
What|Removed |Added
CC||c...@benjamin-thaut.de
--- Comment #7 from Benjamin Thaut c...@benjamin-thaut.de 2012-10-03 07:04:16
PDT ---
(In reply to comment #6)
I've hit this one today and failed to workaround it in any acceptable way.
This is the workaround used in phobos, it works pretty well for me too.
private mixin template _workaround4424()
{
@disable void opAssign(typeof(this) );
}
mixin _workaround4424;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8747] New: isAssignable!(int, const(int)) is false
http://d.puremagic.com/issues/show_bug.cgi?id=8747 Summary: isAssignable!(int, const(int)) is false Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: Phobos AssignedTo: verylonglogin@gmail.com ReportedBy: verylonglogin@gmail.com --- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-03 20:57:01 MSD --- --- static assert( isAssignable!(int, immutable(int))); // fails --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8747] isAssignable!(int, const(int)) is false
http://d.puremagic.com/issues/show_bug.cgi?id=8747 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2012-10-03 21:01:35 MSD --- https://github.com/D-Programming-Language/phobos/pull/832 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8748] New: the module name must not be unique in the pack and its subpacks
http://d.puremagic.com/issues/show_bug.cgi?id=8748
Summary: the module name must not be unique in the pack and its
subpacks
Product: D
Version: D2
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: blazej.podsia...@gmail.com
--- Comment #0 from Blazej Podsiadlo blazej.podsia...@gmail.com 2012-10-03
14:21:07 PDT ---
Created an attachment (id=1145)
the full use case
Hi,
I've got following problem:
It's possible to build following library:
the_lib/
├── sub_pack
│ └── the_mod.d
└── the_mod.d
by following commands:
mkdir -p build/the_lib
mkdir -p build/the_lib/sub_pack
cd build
dmd -c -I../ ../the_lib/sub_pack/the_mod.d -ofthe_lib/sub_pack/the_mod.o
dmd -c -I../ ../the_lib/the_mod.d -ofthe_lib/the_mod.o
dmd -lib -I../ the_lib/the_mod.o the_lib/sub_pack/the_mod.o
-ofthe_lib/libTheLib
However it's not possible to use it later on:
import the_lib.the_mod;
import the_lib.sub_pack.the_mod;
import std.stdio;
void main()
{
writeln(the_app::main());
the_lib.the_mod.the_fun();
the_lib.sub_pack.the_mod.the_fun();
}
built by:
dmd -c -I../ ../the_app/main.d -ofthe_app/main.o
dmd the_app/main.o the_lib/libTheLib.a -ofthe_app/main
produces:
../the_app/main.d(2): Error: module the_mod from file
../the_lib/sub_pack/the_mod.d conflicts with another module the_mod from file
../the_lib/the_mod.d
=
in the same time when I try following code:
[developer@prv-dev-srv dmd-bug]$ cat the_app/clue.d
import the_lib.sub_pack.the_mod;
import std.stdio;
void main()
{
writeln(the_app::main());
the_lib.sub_pack.the_mod.the_fun();
}
compiles, but doesn't work as intended:
execution of: the_lib.sub_pack.the_mod.the_fun();
executes code of the_lib.the_mod.the_fun();
I think that case, is much more serious than the first one because leads to
unexpected behaviours and does not produce any warnings/errors.
===
I've attached the preprepared project demonstrating that issue (dmd-bug) and
as well some workaround (dmd-fine) where all modules have unique names.
===
I use DMD 2.60 @ CentOS 6.3 32bit.
Best Regards,
Blazej Podsiadlo
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8749] New: Wrong mangling of in parameters
http://d.puremagic.com/issues/show_bug.cgi?id=8749
Summary: Wrong mangling of in parameters
Product: D
Version: D2
Platform: All
OS/Version: All
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 2012-10-03
16:00:33 PDT ---
import std.stdio;
void foo(const int x) { }
void bar(const scope int x) { }
void doo(in int x) { }
void main()
{
writeln(foo.mangleof);
writeln(bar.mangleof);
writeln(doo.mangleof);
}
_D4test3fooFxiZv
_D4test3barFMxiZv
_D4test3dooFxiZv
'doo' should have the same mangling as 'bar', but it has mangling as 'foo'.
Fixing this will fix Issue 8695.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8444] Cannot use dot to disambiguate between local method and class declaration
http://d.puremagic.com/issues/show_bug.cgi?id=8444 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-03 20:17:10 PDT --- Looking at the DMD code I think my bug report is invalid. Dot looks up in the module scope, but there's no 'test' in the test module scope (unless it's an import of another module named 'test'). The OP code needs to use .Foo instead. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8444] Cannot use dot to disambiguate between local method and class declaration
http://d.puremagic.com/issues/show_bug.cgi?id=8444
--- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-03
20:19:20 PDT ---
(In reply to comment #3)
Looking at the DMD code I think my bug report is invalid. Dot looks up in the
module scope, but there's no 'test' in the test module scope (unless it's an
import of another module named 'test').
The OP code needs to use .Foo instead.
Also if clashes are of concern, the user can use an alias:
alias test ThisModule;
class Foo
{
void foo(.ThisModule.Foo) { }
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8733] Normalize -of path on Windows
http://d.puremagic.com/issues/show_bug.cgi?id=8733
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-03
20:33:23 PDT ---
(In reply to comment #1)
*** Issue 8736 has been marked as a duplicate of this issue. ***
Guys is this safe to implement this way?:
mars.c:
void toWinPath(char* src)
{
if (src != NULL)
{
while (*src != '\0')
{
if (*src == '/')
*src = '\\';
src++;
}
}
}
case 'f':
if (!p[3])
goto Lnoarg;
#if TARGET_WINDOS
toWinPath(p + 3);
#endif
It works in simple cases but I'm worried about any Unicode issues and of course
UNC paths and whatnot. Is there any standard WinAPI/DMC API function that
normalizes the path (converts '/' to '\')?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8017] Shadowing declaration not detected in opApply
http://d.puremagic.com/issues/show_bug.cgi?id=8017
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Summary|Shadowing declaration not |Shadowing declaration not
|detected when iterating |detected in opApply
|hashes |
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-03
20:48:35 PDT ---
Changing title as this seems related to opApply. This passes:
struct Foo
{
int opApply(int delegate(int, int) dg) { return 1; }
}
void main()
{
int foo;
foreach (a, b; Foo())
{
string foo = ;
}
}
foreach on a hash probably expands to some opApply code and we end up with the
same thing as this sample (just a guess though).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8750] New: ICE when using any and all as a template condition
http://d.puremagic.com/issues/show_bug.cgi?id=8750
Summary: ICE when using any and all as a template condition
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: daniel...@bigpond.com
--- Comment #0 from Daniel Cousens daniel...@bigpond.com 2012-10-03 21:22:41
PDT ---
import std.stdio : writeln;
import std.algorithm : any, all, countUntil, canFind;
struct mystruct {
int a, b;
}
int myfunc(string sw, R ...)(mystruct v) if (all!(x = any!(y = x ==
y)(R))(sw)) { // FIXME: Breaks DMD
return mixin(v. ~ sw[0] ~ + v. ~ sw[1]);
}
void main() {
mystruct z = {3, 4};
writeln(myfunc!(aa, 'a', 'b')(z));
}
DPaste: http://dpaste.dzfl.pl/fe062cd3
ICE: dmd: mangle.c:81: char* mangle(Declaration*): Assertion `fd
fd-inferRetType' failed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8750] ICE when using any and all as a template condition
http://d.puremagic.com/issues/show_bug.cgi?id=8750 --- Comment #1 from Daniel Cousens daniel...@bigpond.com 2012-10-03 21:38:47 PDT --- The intention of the above is: all!(x = x in R)(sw). Therefore, the clearer code (still fails) would be: all!(x = any!(x)(R))(sw) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
