[Issue 6857] Precondition contract checks should be statically bound.

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #87 from deadalnix deadal...@gmail.com 2013-01-10 00:41:57 PST ---
(In reply to comment #85)
 I've had the opportunity to discuss the matter with Bertrand Meyer himself and
 with a graduate student of his. Bertrand didn't have a defined answer offhand,
 but opined that the static contract should be evaluated. His book says the 
 same
 .
 

You are lucky. I wrote him about that and he never answered me :'( .

 So we currently do what the Eiffel standard and compiler do, but not what 
 would
 probably be the most sensible thing. In my opinion we should do the right 
 thing
 and check the contract statically.

I think that this is the sane thing to do. However, this is tricky
implementationwise.

Maybe we should update this bug report's tag according to what you announced
here : http://forum.dlang.org/thread/kcijgh$25h6$1...@digitalmars.com

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7152] Can't assign null to default argument

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7152


Denis Shelomovskij verylonglogin@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||verylonglogin@gmail.com
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8354] Some missing import std.math to use ^^ operator error messages

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8354


Puneet Goel pun...@coverify.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||pun...@coverify.org
 Resolution|FIXED   |


--- Comment #4 from Puneet Goel pun...@coverify.org 2013-01-10 01:00:20 PST 
---
If std.math is imported in one module and power (^^) expression is used in
another module and both the modules are compiled together, we again see the
same confusing error:

bar.d(1): Error: undefined identifier 'std'


Here is the testcase (compile with -- dmd foo.d bar.d):

// File foo.d
import std.math;
void foo() { }

// File bar.d
void bar(int i) { 2^^i; }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #20 from Don clugd...@yahoo.com.au 2013-01-10 01:14:30 PST ---
(In reply to comment #18)
 (In reply to comment #17)
  Windows inserts a guard page that is hardware protected beyond the end of 
  the
  allocated stack. A stack overflow runs into that guard page, which throws a 
  seg
  fault.
  
  It does not corrupt memory.
 
 What about the rest of the platforms?

On our code (Linux only, derived from Tango, its basically the same as
druntime) our fibers allocate a guard page at the end of the stack. We added
this because we found that stack overflows in fibers are easy to create but
difficult to debug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9290] New: Ability to modify immutable as static array assignment is allowed when it must not

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9290

   Summary: Ability to modify immutable as static array assignment
is allowed when it must not
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: accepts-invalid
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com


--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-01-10 
12:31:45 MSK ---
---
struct S
{ immutable int i; }

void main()
{
S s1 = { 1 }, s2 = { 2 };
static assert(!__traits(compiles, s1 = s2)); // ok

S[1] sArr1 = { 1 }, sArr2 = { 2 };
static assert(!__traits(compiles, sArr1 = s2)); // fails
static assert(!__traits(compiles, sArr1 = sArr2)); // fails
}
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #21 from bearophile_h...@eml.cc 2013-01-10 01:46:38 PST ---
(In reply to comment #17)
 Windows inserts a guard page that is hardware protected beyond the end of 
 the
 allocated stack. A stack overflow runs into that guard page, which throws a 
 seg
 fault.
 
 It does not corrupt memory.

So what's missing is just the stack trace.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Leandro Lucarella leandro.lucare...@sociomantic.com changed:

   What|Removed |Added

 CC||leandro.lucarella@sociomant
   ||ic.com


--- Comment #1 from Leandro Lucarella leandro.lucare...@sociomantic.com 
2013-01-10 02:19:27 PST ---
(In reply to comment #0)
 This regression is introduced by the Make deprecations as warnings the
 default.
 From my comment:
 https://github.com/D-Programming-Language/dmd/pull/1287#issuecomment-12080557
[...]
 Therefore this is a huge breaking against the language improvement process in
 the past few years.

How the default deprecation handling is changed compared to using -d in 2.060?
I'm not entirely convinced is really a regression if is the same.

I understand there is a problem, but I wonder if your suggested solution is
really needed:

 To fix the problem, we need to split deprecated language features into the 
 two.

Truly deprecated features
This group contains all language features which already deprecated in 
 2.060 and earlier.
Each of them prints deprecated message without -d switch.
Each of them raises an error without -d switch. (Important!!)

Softly deprecated features
This group will print deprecation message for the using but not make an 
 error in default, and may contain newly deprecated features from 2.061.
Each of them prints deprecated message without -d switch.
Each of them raises an error without -de switch. (Important!!)

Shouldn't be just plain errors the things that you don't want to allow them at
all? Or are you suggesting just a migration path to the new way of presenting
deprecations?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2013-01-10 02:37:57 
PST ---
 I brushed up my idea: The -dw/-de switches affect to the use of deprecated
 symbols, but doesn't to the use of deprecated language features.

That's probably the right way to handle it. Deprecated language features
already effectively have the separation between soft and hard deprecation,
because they generally get normal warnings before being deprecated, whereas
deprecated symbols aren't part of that, since they aren't hard-coded into the
compiler.

We can just go back to treating deprecated language features the way that we
have and take advantage of the recent changes to deprecated for deprecated
symbols.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8078] receiveOnly should tell which type it expected and got on mismatch

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8078



--- Comment #2 from github-bugzi...@puremagic.com 2013-01-10 05:02:00 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/8592a34d4b3f958af2bdadc30f158d67ed286a5a
Fixes Issue 8078 - receiveOnly exceptions should be informative.

https://github.com/D-Programming-Language/phobos/commit/f1ad5d359c3a37a67fdc83dfcd9a8c64d37a01c6
Merge pull request #1062 from AndrejMitrovic/Fix8078

Issue 8078 - receiveOnly exceptions should be informative

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8078] receiveOnly should tell which type it expected and got on mismatch

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8078


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9288] Parameter(Identifier|DefaultValue)Tuple report pointless errors

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9288



--- Comment #2 from github-bugzi...@puremagic.com 2013-01-10 05:02:56 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/f6f57530a64c045c434a473efcd6492d60711068
fix Issue 9288 - Parameter(Identifier|DefaultValue)Tuple report pointless
errors

https://github.com/D-Programming-Language/phobos/commit/bfb6d3d2f386abedbc9aaa850665234d040a0731
Merge pull request #1064 from 9rnsr/fix9288

Issue 9288 - Parameter(Identifier|DefaultValue)Tuple report pointless errors

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8586] [ICE] (module.c, line 829) with -noboundscheck and local import

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8586


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


--- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
05:50:57 PST ---
Can't reproduce in 2.061 release.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7842] ICE(cgcs.c) 517 with struct literal field increment

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7842


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||DUPLICATE


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
05:57:00 PST ---
*** This issue has been marked as a duplicate of issue 3865 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3865] ICE(cgcs.c): Assigning to struct literal member

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3865


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
05:57:00 PST ---
*** Issue 7842 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 7522] ICE(interpret.c) Accessing a non-static member without this

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7522


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com
Version|D1  D2 |D1


--- Comment #8 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
05:59:23 PST ---
Can't reproduce in 2.061 release or git-head, removing D2 tag.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9281] Enum struct with op overloading doesnt works

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9281



--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-01-10 06:22:48 PST ---
Did this really work with 2.060? I cannot reproduce the works 2.060.

Column.opAssign is an immutable member function, then we can call it from
immutable object test1, but cannot call from mutable object test2.

So, the error in test2 = something else is correct, as far as I know.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6743] ICE(mars.c) attempting to compile an exe file

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6743


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
 CC||andrej.mitrov...@gmail.com
 AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
06:53:34 PST ---
https://github.com/D-Programming-Language/dmd/pull/1460

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #4 from Leandro Lucarella leandro.lucare...@sociomantic.com 
2013-01-10 06:56:59 PST ---
I still don't understand why is it a good idea to treat deprecated language
features differently from deprecated symbols. Deprecated language features get
a warning but you only get a warning if you use -w, which implies having
warnings for lots of other stuff that have nothing to do with deprecations.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #5 from Leandro Lucarella leandro.lucare...@sociomantic.com 
2013-01-10 07:03:04 PST ---
Well I see the second example from Kenji doesn't print any warnings, that's
certainly a problem. But the first example works just fine, it compiles issuing
a warning. That is what it's supposed to do, that was the original idea. Is not
a bug, is a feature :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6538] ICE(mangle.c) Invalid template constraints

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6538


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
07:10:24 PST ---
 // This is invalid because allSatisfy is passed sizes, not I.

I don't think this is invalid because T... accepts aliases. It's not what the
user wants, but it's valid code, e.g.:

template isIntegral(T)
{
enum bool isIntegral = true;
}

template allSatisfy(alias z, F...)
{
enum bool allSatisfy = true;
}

void foo(T)(T x, T y)
if (allSatisfy!(isIntegral, x, y))  // compiles fine
{ }

void main()
{
foo(1, 2);
}

The stacktrace for OP sample:

0012e340  004a86f7  DMD!halt+0x5(...)
0012e394  004a85d7  DMD!mangle+0x163
0012e3ec  004a87e9  DMD!mangle+0x43
0012e434  0044fa3b  DMD!Declaration::mangle()+0xce(...)
0012e4a0  0044e08d  DMD!TemplateInstance::genIdent(ArrayBaseObject *)+0x2c0
0012e5a8  0044d93a  DMD!TemplateInstance::semantic(Scope*,ArrayBaseExpression
*)+0x4d5
0012e5bc  0042995d  DMD!TemplateInstance::semantic(Scope*)+0x14
0012e620  0044791c  DMD!ScopeExp::semantic(Scope*)+0x4a
0012e9b4  004483d1  DMD!+0x1ee6
0012eb84  004339d6 
DMD!TemplateDeclaration::deduceFunctionTemplate(Scope*,Loc,ArrayBaseObject
*,Expression*,ArrayBaseExpression *,int )+0x426
0012f050  004809fa  DMD!CallExp::semantic(Scope*)+0x1e18
0012f068  004811de  DMD!ExpStatement::semantic(Scope*)+0x24
0012f25c  004695b9  DMD!CompoundStatement::semantic(Scope*)+0xe5
0012fb00  0049b523  DMD!FuncDeclaration::semantic3(Scope*)+0x1430
0012fb30  00404d29  DMD!Module::semantic3()+0xc3(...)
0012ff44  0040546b  DMD!tryMain+0x281a
0012ff80  00565111  DMD!main+0x43
0012ffc0  7c817067  DMD!mainCRTStartup+0xa9
0012fff0    0x7c817067

It's some kind of mangling issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6107] ICE(expression.c) when a non-template member named '__ctor' exists in a struct, and the constructor is attempted to be invoked.

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6107


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
07:14:02 PST ---
(In reply to comment #1)
 Names beginning with a double underscore are reserved for the compiler's use.

Should we implement some kind of identifier checks in the front-end? We could
gather all double-underscore symbols the compiler uses and just compare them
when instantiating Identifier from user-code.

Unless the compiler also generates these symbols with random names, in such a
case we would have to ban all double-underscores identifiers in user-code
because they might potentially clash.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8742] Anonymous nested class derived from another nested class makes DMD crash

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8742


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
07:30:02 PST ---
Is this valid code to begin with?

@Kenji @Walter: `toParent2()-getType()` returns NULL, hence isBaseOf crashes
when it tries to call `t-ty` on a NULL `t`. I can add a check to `isBaseOf`,
then it will return:

test.d(11): Error: class test.main.__anonclass1 is nested within main, but
super class D is nested within C
test.d(11): Error: e.new is only for allocating nested classes

So it would turn the ICE into an error, but is that ok or is the code actually
valid?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8456] DMD crash with variadic base-class ctor and non-variadic subclass ctor

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8456


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||WORKSFORME


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
07:32:00 PST ---
2.061+: 

test.d(8): Error: constructor test.B.this no match for implicit super() call in
implicitly generated constructor

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8586] [ICE] (module.c, line 829) with -noboundscheck and local import

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8586



--- Comment #5 from jens.k.muel...@gmx.de 2013-01-10 07:32:51 PST ---
Me neither. Tested on Linux.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8888] enums with initializers inside functions cause linker error

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


--- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
07:37:02 PST ---
The pull for Issue 6057 fixes this.

*** This issue has been marked as a duplicate of issue 6057 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6057] Problem with defining enum in function

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6057



--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
07:37:02 PST ---
*** Issue  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 9281] Enum struct with op overloading doesnt works

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9281



--- Comment #2 from Daniel Kozak kozz...@gmail.com 2013-01-10 07:42:45 PST ---
(In reply to comment #1)
 Did this really work with 2.060? I cannot reproduce the works 2.060.
 
 Column.opAssign is an immutable member function, then we can call it from
 immutable object test1, but cannot call from mutable object test2.
 
 So, the error in test2 = something else is correct, as far as I know.

Yes my fault, I try to simplify too much. Here is more detailed description

Code which works on 2.060 and don`t compile on 2.061

module main;

import std.algorithm;
import std.array;

immutable struct Column {

string opAssign(V)(V tValue) {
return tValue;
}
}

class Ob2 {
enum : Column {
COLUM_A = Column()
}

immutable COLUMNS = [
COLUM_A,
];
}

immutable test1 = Column();

void main(string[] args)
{
string where = test1 = something; // works ok
std.stdio.writeln(where);
where = (Ob2.COLUM_A = something else); // works 2.060, dont compile on
2.061
std.stdio.writeln(where);
}


However I find out more interesing thing. This code is almost same however it
doesn`t work on 2.061 neither 2.060:

module main;

import std.algorithm;
import std.array;

immutable struct Column {

string opAssign(V)(V tValue) {
return tValue;
}
}

class Ob2 {
enum : Column {
COLUM_A = Column()
}

// comment this code make it not compilable in 2.060
/*immutable COLUMNS = [
COLUM_A,
];*/
}

immutable test1 = Column();

void main(string[] args)
{
string where = test1 = something; // works ok
std.stdio.writeln(where);
where = (Ob2.COLUM_A = something else); // dont compile on 2.060 and
2.061
std.stdio.writeln(where);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #22 from Andrei Alexandrescu and...@erdani.com 2013-01-10 
09:08:49 PST ---
How large are the guard pages on each OS?

We should either restrict object size to a reasonable maximum, or insert
runtime checks at least in @safe mode when accessing fields through pointers
that may be null.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #23 from Andrei Alexandrescu and...@erdani.com 2013-01-10 
09:12:28 PST ---
Oh there's also a confusion. The problem is not with the stack, it's with
accessing fields through null pointers. Getting back to the original example:

struct S {
char raw[100_000];
}

void main() {
  S * s = null;
  char a = raw[$ - 1];
}

That will issue an access through a pointer with a small value (100_000). The
question is what is the maximum small pointer that will cause a protection
fault on all OSs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6857] Precondition contract checks should be statically bound.

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #88 from Andrei Alexandrescu and...@erdani.com 2013-01-10 
09:14:02 PST ---
@Walter: would you preapprove this?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5507] countUntil should take Ranges... instead of R2

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5507


Brad Anderson e...@gnuk.net changed:

   What|Removed |Added

 CC||e...@gnuk.net


--- Comment #2 from Brad Anderson e...@gnuk.net 2013-01-10 09:33:35 PST ---
Hit this answering a StackOverflow question
http://stackoverflow.com/q/14262766/216300.  My solution (using countUntil()
on the result of find() with multiple needles) requires two passes which is
unfortunate since there should only need to be one pass.

There is probably a way to avoid this that I didn't see but whatever it is is
probably just as convoluted as my solution.  countUntil should really just
accept multiple needles so consider this my +1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9291] New: [ICE] throwing undefined identifier with nothrow crashes dmd

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9291

   Summary: [ICE] throwing undefined identifier with nothrow
crashes dmd
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com


--- Comment #0 from monarchdo...@gmail.com 2013-01-10 10:08:06 PST ---
//
void foo() nothrow
{
throw new Hello();
}
//

Produces:
//
main.d(3): Error: undefined identifier Hello
Assertion failure: 'cd' on line 5048 in file 'statement.c'

abnormal program termination
//

This is a regression introduced in 2.061, which was probably caused by:
http://d.puremagic.com/issues/show_bug.cgi?id=8675

https://github.com/D-Programming-Language/dmd/commit/d77b7c2bf456e99495d8a6644a6304995d1a3b20

In 2.060, the error produced is:
//
main.d(3): Error: undefined identifier Hello
main.d(3): Error: _error_ is thrown but not caught
main.d(1): Error: function main.foo 'foo' is nothrow yet may throw
//

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #24 from Jacob Carlborg d...@me.com 2013-01-10 10:14:47 PST ---
(In reply to comment #22)
 How large are the guard pages on each OS?
 
 We should either restrict object size to a reasonable maximum, or insert
 runtime checks at least in @safe mode when accessing fields through pointers
 that may be null.

Perhaps doing something similar as with array bounds checking. Insert a check
and provide a compiler flag to remove it. Or remove the check in -release
builds.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9291] [ICE][REG] throwing undefined identifier with nothrow crashes dmd

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9291


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
 CC||andrej.mitrov...@gmail.com
 AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
10:20:42 PST ---
https://github.com/D-Programming-Language/dmd/pull/1461

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9287] DMD should read from stdin when an input file is -

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9287


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
10:24:49 PST ---
This is problematic because DMD uses single dash for arguments, if you
accidentally run DMD with:

$ dmd -arg1 - arg2 -arg3

You're going to get some pretty awful error messages if DMD tries to read this.
But you can already use RDMD for this via `--eval=code`, why reimplement this
in DMD?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8742] Anonymous nested class derived from another nested class makes DMD crash

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8742



--- Comment #2 from David Eckardt david.ecka...@sociomantic.com 2013-01-10 
10:43:28 PST ---
It sounds plausible to me that the code is invalid due to wrong nesting; I
didn't notice that, sorry.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8941] Documentation for the Yes struct in Phobos std.typecons appears incorrect

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8941


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||WORKSFORME


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
11:01:30 PST ---
Fixed in 2.061

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8727] __traits(is_reserved_word, ) ?

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8727


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #9 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
11:23:57 PST ---
(In reply to comment #7)
 I wrote the code, the documentation, and the unit tests. The thing though is
 that I don't really care for this enhancement, and don't feel like pushing for
 it.

This is actually very useful for generic code, it allows one to generate
identifiers while ensuring they don't conflict with keywords.

It's also useful in code generators written in D, which can use this function
to generate C/C++ wrappers code which doesn't conflict with D keywords.

I'd say make it a pull, it's your work after all. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9292] New: hasNestedArgs wrong result for nested template literal

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9292

   Summary: hasNestedArgs wrong result for nested template literal
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: johannesp...@gmail.com


--- Comment #0 from Johannes Pfau johannesp...@gmail.com 2013-01-10 11:25:00 
PST ---
Created an attachment (id=1178)
test case

When compiling testcase.d, hasNestedArgs returns these results:

topNIndex!() nested=0
Test!(indirectLess) nested=1
BinaryHeap!(Test()) nested=0

AFAIK BinaryHeap!(Test()) should also be marked as nested, as it needs
Test!(indirectLess) which is nested?

I'm not sure if this causes a real problem in dmd, but we use
hasNestedArgs/isnested in gdc to tell the backend if the instantiated template
is accessible from other modules.

Therefore this test case currently ICEs gdc (also depends on gcc version. Some
are more picky)

BTW: Would it be OK to mark this as blocker, as it blocks gdc from compiling
that test case?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #25 from hst...@quickfur.ath.cx 2013-01-10 11:46:07 PST ---
(In reply to comment #17)
 Windows inserts a guard page that is hardware protected beyond the end of 
 the
 allocated stack. A stack overflow runs into that guard page, which throws a 
 seg
 fault.
 
 It does not corrupt memory.

Oh yes it does:

http://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=448588

(But I did make a mistake, it's not Linux that this happens on, but OSX/64.)

For reference, this is the failing code (N.B. the last assert, compare with
output in the autotester, you can see that garbage values are produced, I've
traced this and found that it's caused by stack overflow):

unittest
{
struct TransientRange
{
dchar[128] _buf;
dstring[] _values;
this(dstring[] values)
{
_values = values;
}
@property bool empty()
{
return _values.length == 0;
}
@property auto front()
{
foreach (i; 0 .. _values.front.length)
{
_buf[i] = _values[0][i];
}
return _buf[0 .. _values.front.length];
}
void popFront()
{
_values = _values[1 .. $];
}
}

auto rr = TransientRange([abcd, 12d, defd, 34d]);

// Can't use array() or equal() directly because they fail with transient
// .front.
dchar[] result;
foreach (c; rr.joiner()) {
result ~= c;
}

assert(equal(result, abc12def34d),
Unexpected result: '%s'd.format(result));
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #26 from Walter Bright bugzi...@digitalmars.com 2013-01-10 
12:03:50 PST ---
(In reply to comment #22)
 How large are the guard pages on each OS?

Usually 4k. But the function prologs, when creating a stack frame larger than
4k, will do probes for each 4k page. So, no, you can't corrupt memory with an
overflow.

 We should either restrict object size to a reasonable maximum, or insert
 runtime checks at least in @safe mode when accessing fields through pointers
 that may be null.

There's a separate set of guard pages at address 0, to cause a seg fault if 1,
2, 3, etc. is accessed. I don't know how big they are.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5176] Limit static object sizes

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5176



--- Comment #27 from Walter Bright bugzi...@digitalmars.com 2013-01-10 
12:08:12 PST ---
 Oh yes it does:

You can test this with a far simpler program. Just write a function that calls
itself and run it under the debugger.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9292] hasNestedArgs wrong result for nested template literal

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9292


Iain Buclaw ibuc...@ubuntu.com changed:

   What|Removed |Added

 CC||ibuc...@ubuntu.com


--- Comment #1 from Iain Buclaw ibuc...@ubuntu.com 2013-01-10 12:44:09 PST ---
(In reply to comment #0)
 Created an attachment (id=1178) [details]
 test case
 
 When compiling testcase.d, hasNestedArgs returns these results:
 
 topNIndex!() nested=0
 Test!(indirectLess) nested=1
 BinaryHeap!(Test()) nested=0
 
 AFAIK BinaryHeap!(Test()) should also be marked as nested, as it needs
 Test!(indirectLess) which is nested?
 
 I'm not sure if this causes a real problem in dmd, but we use
 hasNestedArgs/isnested in gdc to tell the backend if the instantiated template
 is accessible from other modules.
 
 Therefore this test case currently ICEs gdc (also depends on gcc version. Some
 are more picky)
 
 BTW: Would it be OK to mark this as blocker, as it blocks gdc from compiling
 that test case?

IIRC, the way DMD does it, all functions are public, even nested ones. I think
I've had this argument before with Alex over whether I should follow suit or
carry on marking nested functions as non-public.  Call by alias is meant to be
a direct call that skips any checks for where the function actually is.  So far
have been special casing these instances as I find them.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4286] Wrong error line number and more with schwartzSort

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4286


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||WORKSFORME


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
14:10:51 PST ---
Works in 2.061+.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6227] Comparison of different enums

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6227



--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
14:59:00 PST ---
*** Issue 8157 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 8157] Disallow (dis)equality among two different enums

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8157


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||DUPLICATE


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
14:59:00 PST ---
*** This issue has been marked as a duplicate of issue 6227 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7662] int[1u] not implicitly convertible to immutable

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7662


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||WORKSFORME


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
15:03:08 PST ---
Works in 2.061+

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8354] Some missing import std.math to use ^^ operator error messages

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8354


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||DUPLICATE


--- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
15:07:59 PST ---
(In reply to comment #4)
 If std.math is imported in one module and power (^^) expression is used in
 another module and both the modules are compiled together, we again see the
 same confusing error:
 
 bar.d(1): Error: undefined identifier 'std'
 
 
 Here is the testcase (compile with -- dmd foo.d bar.d):
 
 // File foo.d
 import std.math;
 void foo() { }
 
 // File bar.d
 void bar(int i) { 2^^i; }

This will be fixed with pull for Issue 9047.

*** This issue has been marked as a duplicate of issue 9047 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9047] Expression requiring std.math fails with function-local import

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9047



--- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
15:07:59 PST ---
*** Issue 8354 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 8807] Better error messages for a switch on doubles

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8807


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
15:50:45 PST ---
(In reply to comment #0)
 temp2.d(3): Error: 'value' is not of integral type, it is a double

This is solved in pull for Issue 4540.

 temp2.d(4): Error: case must be a string or an integral constant, not 1
 - The second error message is just wrong, because 1 is on default an integral
 constant.

It's not actually wrong, 1 is implicitly converted to type double.
Unfortunately it doesn't print 1.0 to make it obvious.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8628] IntegerExp::toInteger(): Assertion `0' failed

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8628


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
16:45:29 PST ---
I can't reproduce with 2.061 on x86 win32. (I can reproduce on 2.060).

Please verify on x64 and then mark as WORKSFORME if it's solved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5140] Add __FUNCTION__

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5140


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
 CC||andrej.mitrov...@gmail.com
Version|unspecified |D2
 AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com
 OS/Version|Linux   |All


--- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
19:44:58 PST ---
https://github.com/D-Programming-Language/dmd/pull/1462

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5140] Add __FUNCTION__

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #5 from bearophile_h...@eml.cc 2013-01-10 20:23:21 PST ---
If __FUNCTION__ gets approved, then probably the probability of __function
getting approved decreases. And I don't care for __FUNCTION__.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9249] Defining opCast disables Upcasting

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9249


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
20:40:57 PST ---
What your sample is showing is downcasting, this is upcasting:

class C1
{
public T opCast(T)()
if (is(T == string))
{
return C1;
}
}

class C2 : C1
{
}

void main()
{
C2 c2;
C1 c1 = cast(C1)c2;
}

Both fail though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8628] IntegerExp::toInteger(): Assertion `0' failed

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8628


Ellery Newcomer ellery-newco...@utulsa.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


--- Comment #3 from Ellery Newcomer ellery-newco...@utulsa.edu 2013-01-10 
20:40:12 PST ---
Doesn't show in linux, 32 or 64 bit.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9249] Defining opCast disables downcasting and explicit upcasting

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9249


Puneet Goel pun...@coverify.org changed:

   What|Removed |Added

Summary|Defining opCast disables|Defining opCast disables
   |Upcasting   |downcasting and explicit
   ||upcasting


--- Comment #2 from Puneet Goel pun...@coverify.org 2013-01-10 20:54:39 PST 
---
Yup, my bad. I have updated the summary as per Andrej's comment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9249] Defining opCast disables downcasting and explicit upcasting

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9249



--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-10 
20:58:23 PST ---
I've tried a version as old as 2.032 which has the same behavior. It's odd this
wasn't picked up before.

What I think should happen is opCast should be tried first, and if it can't be
instantiated try to do the regular upcast/downcast.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9293] New: enum struct with StructInitializer reports weird error

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9293

   Summary: enum struct with StructInitializer reports weird error
   Product: D
   Version: D2
  Platform: All
OS/Version: All
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 2013-01-10 22:03:36 PST ---
Spin-off from bug 9218. This code should run without assertion, but the
compilation fails with weird error message.

struct A
{
//  enum A zero = A(); // This works as expected
enum A zero = {};  // Note the difference here

int opCmp(const ref A a) const
{
assert(0);
}

int opCmp(const A a) const
{
return 0;
}
}

void main()
{
A a;
auto b = a = A.zero;  // Error: A() is not an lvalue
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9218] [2.061] Correct signature of struct opCmp no longer accepts enum structs

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9218



--- Comment #10 from Kenji Hara k.hara...@gmail.com 2013-01-10 22:08:42 PST 
---
(In reply to comment #9)
 Ok, that workabout is not quite complete (perhaps this is a different bug
 now?). While it solves the code in the original comment, this code doesn't
 work:
 
[snip]
 
 Why would enum A zero = A(); work but enum A zero = {}; not work? Is it safe
 (in terms of inadvertent GC usage) to use A() instead of {}?

This is a different bug which is unrelated to the ref-non-ref overloading.
I opened a new bug report.

Issue 9293 - enum struct with StructInitializer reports weird error

So this is an invalid bug, because:

(In comment #1)
 Struct literals (manifests included) are no longer lvalues in 2.061, this is 
 by
design.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9293] enum struct with StructInitializer reports weird error

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9293


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-01-10 22:14:41 PST ---
https://github.com/D-Programming-Language/dmd/pull/1464

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9281] Enum struct with op overloading doesnt works

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9281



--- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-01-10 22:52:17 PST ---
(In reply to comment #2)
 Yes my fault, I try to simplify too much. Here is more detailed description
 
 Code which works on 2.060 and don`t compile on 2.061
 
[snip]

The reason why (Ob2.COLUM_A = something else) doesn't work in 2.061 is same
as in comment #1. typeof(Ob2.COLUM_A) is a mutable Column, and cannot call
immutable opAssign from that.

 However I find out more interesing thing. This code is almost same however it
 doesn`t work on 2.061 neither 2.060:
 
[snip]

I think this _was_ an accepts-invalid bug in 2.060.
If you define Ob2.COLUMNS in 2.060, Ob2.COLUM_A is _incorrectly_ typed as
immutable(Column). This is definitely a bug (But I don't know what change is
fixed the bug in 2.060).

So, this is not a regression.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 9281] Enum struct with op overloading doesnt works

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9281


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


--- Comment #4 from Kenji Hara k.hara...@gmail.com 2013-01-10 23:16:33 PST ---
(In reply to comment #3)
 I think this _was_ an accepts-invalid bug in 2.060.
 If you define Ob2.COLUMNS in 2.060, Ob2.COLUM_A is _incorrectly_ typed as
 immutable(Column). This is definitely a bug (But I don't know what change is
 fixed the bug in 2.060).

I found a commit which the behavior is changed.

https://github.com/D-Programming-Language/dmd/commit/e01eb59f842dfe7a5275d96c420691c4a64f57f4

The root cause of the bug 5779 was an optimizer bug. 
If the type of an optimized result is different from the type of a source
expression, the source expression type had been accidentally modified.

In this case, the declaration of COLUMNS invokes optimizer on the expression [
COLUM_A, ], and it accidentally modified the type of COLUM_A to
immutable(Column).

So the conclusion is: the original code had an accepts-invalid bug, and it was
already fixed in 2.061.

I'll mark this as resolved-invalid bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5140] Add __FUNCTION__

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5140



--- Comment #6 from Rob T al...@ucora.com 2013-01-10 23:24:01 PST ---
(In reply to comment #2)
 See a better explanations and some examples of __function:
 http://rosettacode.org/wiki/Anonymous_recursion
 

I really would love to have the ability to perform anonymous recursion.

As for the name __FUNCTION__ I don't really like the convention either, but
since it is related to __LINE__ and __FILE__, you'd probably have to depreciate
those too so as to remain consistent.

This is great news if it gets accepted because I need it for log tracing, but
I'd also like to see a version of this that displays the full function
signature which allows you to see which overload or template version was
called. I don't know if the patch does this or not. 

--rt

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4540] Better error message for wrong switch type

2013-01-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4540



--- Comment #2 from github-bugzi...@puremagic.com 2013-01-10 23:54:43 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/8ab6ab22b7e7d160732d72c71e9953e750f6b1be
Fixes Issue 4540 - Better diagnostic for wrong switch type.

https://github.com/D-Programming-Language/dmd/commit/98e20bc85dbfd63e11a607c813fc6ae73554b631
Merge pull request #1417 from AndrejMitrovic/Fix4540

Issue 4540 - Better diagnostic for wrong switch type.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---