[Issue 7548] Less specific lowering of power operator was chosen, causing 10.0L^^2 == 99.999999999999999993L
http://d.puremagic.com/issues/show_bug.cgi?id=7548 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||DUPLICATE --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-03 22:57:15 PDT --- *** This issue has been marked as a duplicate of issue 11159 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11110] Variant.convertsTo doesn't work like isImplicitlyConvertible
http://d.puremagic.com/issues/show_bug.cgi?id=0
blm...@gmail.com changed:
What|Removed |Added
CC||blm...@gmail.com
--- Comment #1 from blm...@gmail.com 2013-10-03 22:59:26 PDT ---
This also applies to arrays:
import std.traits;
import std.variant;
void main() {
assert(isImplicitlyConvertible!(string, const(char)[])); //passes
Variant var = some_string;
assert(var.convertsTo!(const(char)[])); //fails
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11159] [CTFE] Integer exponentiation give incorrect values
http://d.puremagic.com/issues/show_bug.cgi?id=11159 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2013-10-03 22:57:15 PDT --- *** Issue 7548 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 11169] cannot create instance of abstract class
http://d.puremagic.com/issues/show_bug.cgi?id=11169 Ali Cehreli acehr...@yahoo.com changed: What|Removed |Added CC||acehr...@yahoo.com --- Comment #1 from Ali Cehreli acehr...@yahoo.com 2013-10-03 23:27:26 PDT --- If others agree, please change the summary to something like __traits(isAbstractClass) uses the definition that it knows so far, not the whole definition of the class In any case, it would be a chicken and egg problem if static if tried to complete the definition of the class. Ali -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11169] cannot create instance of abstract class
http://d.puremagic.com/issues/show_bug.cgi?id=11169 --- Comment #2 from Zhouxuan pyc...@qq.com 2013-10-03 23:48:02 PDT --- (In reply to comment #1) If others agree, please change the summary to something like __traits(isAbstractClass) uses the definition that it knows so far, not the whole definition of the class In any case, it would be a chicken and egg problem if static if tried to complete the definition of the class. Ali How about follow the rules of checking recursive alias? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11164] wrong dependencies generated when compiling with -main
http://d.puremagic.com/issues/show_bug.cgi?id=11164 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||pull --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2013-10-03 23:53:00 PDT --- https://github.com/D-Programming-Language/dmd/pull/2626 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7955] Nested function error in sort with lambda template but not with a lambda
http://d.puremagic.com/issues/show_bug.cgi?id=7955 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com 2013-10-04 11:16:19 MSD --- Like Issue 7917 it compiles fine now. Then crashes at a runtime because of infinite recursion. Please open a new issue is there is a problem with `sort`. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11171] Text relocations in Phobos shared library
http://d.puremagic.com/issues/show_bug.cgi?id=11171 --- Comment #1 from Dicebot pub...@dicebot.lv 2013-10-04 04:14:41 PDT --- P.S. version of shared library in question is https://www.archlinux.org/packages/community/x86_64/libphobos/ , it can be installed at any point by standard package manager (pacman) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11164] wrong dependencies generated when compiling with -main
http://d.puremagic.com/issues/show_bug.cgi?id=11164 --- Comment #2 from github-bugzi...@puremagic.com 2013-10-04 04:12:30 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3e1a00951baed32c81a0e13e8d50901603a737ad Merge pull request #2626 from rainers/issue11164 fix issue 11164: do not output __main.d as dependency -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11169] cannot create instance of abstract class
http://d.puremagic.com/issues/show_bug.cgi?id=11169 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04 04:32:31 PDT --- (In reply to comment #1) If others agree, please change the summary to something like __traits(isAbstractClass) uses the definition that it knows so far, not the whole definition of the class Internal note: The issue is that __traits(isAbstractClass) has side-effects. It will call `ClassDeclaration::isAbstract`, but this will not only return the result but also set the internal `isabstract` field for the class (damn getter functions with side-effects..). I guess semantic() wasn't called on the class at that point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11172] New: Allow scoped assignment of version and debug statements
http://d.puremagic.com/issues/show_bug.cgi?id=11172
Summary: Allow scoped assignment of version and debug
statements
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04
07:36:56 PDT ---
-
void foo() { }
void main()
{
version = CALL_FOO;
version (CALL_FOO)
{
foo();
}
debug = DEBUG_FOO;
debug (DEBUG_FOO)
{
foo();
}
}
-
$ dmd test.d
test.d(5): Error: (condition) expected following version
test.d(5): Error: found '=' instead of statement
test.d(11): Error: found '=' instead of statement
Allowing this would mean the version/debug identifiers were valid inside the
scope of the assignment. Outside of main() a version(CALL_FOO) body would not
be entered.
The workaround is use to use enums and static if:
-
void foo() { }
void main()
{
enum CALL_FOO = 1;
static if (CALL_FOO)
{
foo();
}
enum DEBUG_FOO = 1;
static if (DEBUG_FOO)
{
foo();
}
}
-
But it would be more convenient to allow the former version/debug syntax,
especially if we want to re-use existing version/debug identifiers.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9066] Add constructor inheritance feature
http://d.puremagic.com/issues/show_bug.cgi?id=9066 --- Comment #6 from Martin Nowak c...@dawg.eu 2013-10-04 11:27:29 PDT --- (In reply to comment #5) Inheriting the default constructor is implicit so why would you need an explicit syntax for non-default constructors? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9066] Add constructor inheritance feature
http://d.puremagic.com/issues/show_bug.cgi?id=9066 --- Comment #7 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04 11:37:43 PDT --- (In reply to comment #6) (In reply to comment #5) Inheriting the default constructor is implicit so why would you need an explicit syntax for non-default constructors? The last time this was discussed (IIRC), people were against this. Maybe my memory is bad. We could have another go at a newsgroup discussion. I haven't yet looked at the C++11 spec, but I wonder why they too haven't made constructor inheritance implicit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9066] Add constructor inheritance feature
http://d.puremagic.com/issues/show_bug.cgi?id=9066
--- Comment #8 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04
12:01:23 PDT ---
(In reply to comment #6)
(In reply to comment #5)
Inheriting the default constructor is implicit so why would you need an
explicit syntax for non-default constructors?
I guess the real issue is that you could easily end up instantiating an object
which hasn't been properly initialized (properly meaning how the class designer
defines it). For example:
-
class A
{
this(float x) { this.x = x; }
float x;
}
class B : A
{
this(float x, float y) { super(x); this.y = y; }
float y;
}
void main()
{
auto b = new B(1.0); // B's ctor not called
}
-
Nevermind that we have .init, a class designer probably wants to have explicit
control of which constructors can be called by the user. If all base class
ctors are inherited.. well you saw the example.
Another interesting example:
-
class A
{
this(float x) { this.x = x; }
float x;
}
class B : A
{
this(float x, float y) { super(x); this.y = y; }
const(float) y;
}
void main()
{
// this should not compile since y must be initialized
// in the class B ctor, which wasn't called.
auto b = new B(1.0);
}
-
So the user could easily get a half-constructed object, or bad diagnostics
about some const field not being initialized.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11172] Allow scoped assignment of version and debug statements
http://d.puremagic.com/issues/show_bug.cgi?id=11172 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2013-10-04 12:01:45 PDT --- I'm pretty strongly opposed to this. These should have module scope, and no other scope. Version and debug identifiers are special and live outside the normal symbol table, and this is on purpose. They cannot be imported from other modules, and do not affect imported modules. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7565] ICE(cg87):202, postincrement of a double parameter, 64-bit only
http://d.puremagic.com/issues/show_bug.cgi?id=7565 --- Comment #4 from github-bugzi...@puremagic.com 2013-10-04 12:06:53 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/88c89c1bcad1210e3a86e649c324b3fe43c4b6f1 Merge pull request #2622 from WalterBright/fix7565 fix Issue 7565 - ICE(cg87):202, postincrement of a double parameter, 64-... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11172] Allow scoped assignment of version and debug statements
http://d.puremagic.com/issues/show_bug.cgi?id=11172
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04
12:15:03 PDT ---
(In reply to comment #1)
They cannot be imported from other
modules, and do not affect imported modules.
Right, but they can be set in the module itself:
-
version = CALL_FOO; // active in this module only
void foo() { }
void main()
{
version (CALL_FOO)
{
foo();
}
}
-
I was looking for a more fine-grained version of this. The reason why is that
two code fragments which are related to each other should also be closer to
each other (in this case CALL_FOO is only used inside a single function). In a
large module I could easily miss that a version switch was set.
Personally I dislike that version/debug statements are global to begin with.
It's only a matter of time before two libraries end up having two conflicting
notions of the same version/debug symbol.
For example if libFoo has a version(SharedLib) block, but libBar also uses this
same version block but for a completely different purpose you will end up
enabling the block for both libraries even if you only wanted to do it for a
single library.
It very much reminds me of a C macro. I guess you can close this, I can use
'static if' instead.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11172] Allow scoped assignment of version and debug statements
http://d.puremagic.com/issues/show_bug.cgi?id=11172 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04 12:32:43 PDT --- (In reply to comment #3) This is exactly why version identifiers are not imported and are not affected by who imports them. They can only be set via the command line or in the module itself. Once you set them at the command line they affect *every* library that you import, that's still an issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7661] ICE(cgcs.c) With return of one fixed size array item
http://d.puremagic.com/issues/show_bug.cgi?id=7661 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WORKSFORME --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2013-10-04 12:31:33 PDT --- Does not happen with 2.064 head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7701] ICE(e2ir.c) on access of instance fn on nested templated struct type
http://d.puremagic.com/issues/show_bug.cgi?id=7701
--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-04
12:36:19 PDT ---
Interestingly, when the template is removed, we get a correct error message:
struct S {
struct S2 {
void fn () {}
}
}
void main () {
S s;
s.S2.fn(); // Error: need 'this' for 'fn' of type 'void()'
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7806] ICE(gloop.c) iterating with idouble, when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=7806
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-04
12:40:44 PDT ---
A simpler version without all the templates:
import core.stdc.stdio;
void main()
{
for (idouble i = -2i; i = 2i; i += .125i)
for (double r = -2; r = 2; r += .0625)
{
cdouble c = r + i;
printf(%g %gi\n, c.re, c.im);
}
}
Which does not produce an internal error with -O, but does go into an infinite
loop when the compiled program is executed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11172] Allow scoped assignment of version and debug statements
http://d.puremagic.com/issues/show_bug.cgi?id=11172 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-10-04 12:52:06 PDT --- (In reply to comment #4) Once you set them at the command line they affect *every* library that you import, that's still an issue. I agree, and library developers should be aware of this and account for it. My recommendation is that library developers need to eschew using generic version identifiers, and instead use a prefix consisting of the library name. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11172] Allow scoped assignment of version and debug statements
http://d.puremagic.com/issues/show_bug.cgi?id=11172
--- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-04
13:02:45 PDT ---
(In reply to comment #5)
My recommendation is that library developers need to eschew using generic
version
identifiers, and instead use a prefix consisting of the library name.
Yeah. I'm doing this in my own libraries too.
But since each library practically owns the toplevel package name (each library
name is unique, after all), we could avoid depending on naming conventions and
instead allow using the package or module name before an identifier:
version (foolib.SharedLib) { }
Then from the command line you would call:
$ dmd -lib -version=foolib.SharedLib foolib.d
Is it overkill? The alternative is to manually encode the name and use
`version=foolib_SharedLib`, but it's a bit ugly.
I could see some use-cases:
version=std.perf_tests = enable performance test suite in all of phobos
version=std.datetime.perf_tests = enable the same just for datetime
Of course these would still be visible globally, but there's no need for name
encoding conventions if this is allowed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7661] ICE(cgcs.c) With return of one fixed size array item
http://d.puremagic.com/issues/show_bug.cgi?id=7661 --- Comment #2 from bearophile_h...@eml.cc 2013-10-04 14:41:40 PDT --- (In reply to comment #1) Does not happen with 2.064 head. I suggest to add a unittest that makes sure this bug keeps being fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10323] getAMDcacheinfo needlessly allocates
http://d.puremagic.com/issues/show_bug.cgi?id=10323 Adam D. Ruppe destructiona...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10323] getAMDcacheinfo needlessly allocates
http://d.puremagic.com/issues/show_bug.cgi?id=10323 --- Comment #6 from Adam D. Ruppe destructiona...@gmail.com 2013-10-04 18:59:13 PDT --- pull # 625 fixed -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3713] Tail call optimization not enabled with the ?: operator
http://d.puremagic.com/issues/show_bug.cgi?id=3713 --- Comment #2 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-04 20:01:14 PDT --- Created an attachment (id=1257) Partial solution I took a stab at this one. I've gotten b2search to compile to the same assembly code as b3search. I did not handle nested ternary operators following a return statement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9844] DMD (-m64) int long initialisation bug
http://d.puremagic.com/issues/show_bug.cgi?id=9844 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||g.sa...@yahoo.es --- Comment #9 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-04 20:48:36 PDT --- *** Issue 9331 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: ---
