[Issue 2474] New: Recursive lazy arguments are inlined incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=2474
Summary: Recursive lazy arguments are inlined incorrectly
Product: D
Version: 2.021
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This code:
--8<---
int foo(lazy int x)
{
int bar()
{
return foo(bar());
}
return bar();
}
--8<---
produces the following output when compiled:
> dmd inlinebug.d -c -inline
inlinebug.d(5): delegate inlinebug.foo.bar.__dgliteral1 is a nested function
and cannot be accessed from foo
Without the -inline flag this code compiles and works as expected.
The same bug is present in DMD 1.037.
--
Re: [Issue 1977] integral arithmetic operation only on int?
On Wed, Nov 26, 2008 at 12:30 PM, Stewart Gordon <[EMAIL PROTECTED]> wrote: > Has the automatic relaying of newsgroup posts to Bugzilla been discontinued, > or does it only work if the email address it's sent from is registered? > > It was probably the right thing to do considering the excessive quoting that > happens too often. I got the impression from Brad that he was surprised that it no longer worked, at least when I mentioned it a couple weeks ago. Maybe some settings just got changed.
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 --- Comment #9 from [EMAIL PROTECTED] 2008-11-26 12:43 --- Sorry, I was far less than clear. writefln in all cases we use it in now executes with the code path, e.g. when the code is executed rather than generated. pragma is compile time in all cases. Seems like a good fit to me. OTOH as long as it's not something like pragma(D9B01F73-E64A-4FA9-A2DE-C20CD24560BA) I'm not going to object to getting it! --
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 --- Comment #8 from [EMAIL PROTECTED] 2008-11-26 12:05 --- (In reply to comment #7) > To date, every use of writefln I've seen has been run time. So it doesn't seem > particularly ambiguous at least to me, That's because at the moment writefln can only be executed at run time. If it (or something resembling it) becomes executable at compile time, it could just as well be either as and when compiled or during CTFE. Having a difference between pragma(msg) and pragma(writefln) beyond what they say on the tin would be arbitrary and confusing. --
Re: [Issue 1977] integral arithmetic operation only on int?
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Could you paste your comment into bugzilla so we have the discussion tracked there? Thanks. Has the automatic relaying of newsgroup posts to Bugzilla been discontinued, or does it only work if the email address it's sent from is registered? It was probably the right thing to do considering the excessive quoting that happens too often. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 --- Comment #6 from [EMAIL PROTECTED] 2008-11-26 11:13 --- >From the names pragma(msg) and pragma(writefln), it isn't clear at all that one's while compiling and one's while evaluating. Better would be to name it something like "ctfeMsg" or "msgCTFE". And perhaps writefln notation could be supported in both this and regular msg. This won't break existing code as long as pragma(msg, string) with no further arguments is still defined to write that exact string. --
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 --- Comment #7 from [EMAIL PROTECTED] 2008-11-26 11:17 --- To date, every use of writefln I've seen has been run time. So it doesn't seem particularly ambiguous at least to me, --
Re: [Issue 1977] integral arithmetic operation only on int?
Don wrote:
[EMAIL PROTECTED] wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=1977
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #5 from [EMAIL PROTECTED] 2008-11-22 08:44 ---
(In reply to comment #4)
It's not ridiculous at all. The compiler cannot tell what values will be
possibly passed to f, and the range of byte and short are
sufficiently small to
make overflow as frequent as it is confusing and undesirable.
Why is this also flagged (no overflow possible):
short f(byte i) {
byte t = 1;
short o = t - i;
return o;
}
The community has insisted for a long time to tighten integral
operations, and
now that it's happening, the tightening is reported as a bug :o).
But it's pretty inconsistent. If I add two random ints together, I
will get an
overflow in 25% of cases, why is that not flagged?
I think the restriction is too tight. People expect to do math on
homogeneous
types without having to cast the result, as they do with ints. And
I'll say I
was not one of the people asking for this 'feature'. I'm not sure
where that
came from.
Personally I think having to insert a cast makes the code more
error-prone. The cure is worse than the disease.
Consider also that with the original code, the compiler could install
debug-time asserts on any such narrowing conversion. Once you insert a
cast, that's impossible, since the language doesn't distinguish between
(a) 'I know that is OK' casts, (b) 'I want to pretend that this is a
different type' casts, and (c) 'I want you to change this into another
type' casts.
Compiler checks should only be inserted for case (a) and (c).
Could you paste your comment into bugzilla so we have the discussion
tracked there? Thanks.
Andrei
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #5 from [EMAIL PROTECTED] 2008-11-26 10:32 --- pragma(writefln,"hello #%d", 1); vote++; --
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 --- Comment #4 from [EMAIL PROTECTED] 2008-11-26 08:52 --- I think we need separate notation for this. Generating a compiler message while compiling a function is conceptually different from generating a compiler message while evaluating it. --
[Issue 1924] Allow pragma(msg) in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=1924 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Keywords|spec| Summary|fail to pragma compile time |Allow pragma(msg) in CTFE |constant| --- Comment #3 from [EMAIL PROTECTED] 2008-11-26 08:35 --- Although a way of debugging CTFE functions would be very nice to have, this is definitely not a bug. I'm changing this to an enhancement, changed title from: fail to pragma compile time constant --
Re: [Issue 1977] integral arithmetic operation only on int?
[EMAIL PROTECTED] wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=1977
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #5 from [EMAIL PROTECTED] 2008-11-22 08:44 ---
(In reply to comment #4)
It's not ridiculous at all. The compiler cannot tell what values will be
possibly passed to f, and the range of byte and short are sufficiently small to
make overflow as frequent as it is confusing and undesirable.
Why is this also flagged (no overflow possible):
short f(byte i) {
byte t = 1;
short o = t - i;
return o;
}
The community has insisted for a long time to tighten integral operations, and
now that it's happening, the tightening is reported as a bug :o).
But it's pretty inconsistent. If I add two random ints together, I will get an
overflow in 25% of cases, why is that not flagged?
I think the restriction is too tight. People expect to do math on homogeneous
types without having to cast the result, as they do with ints. And I'll say I
was not one of the people asking for this 'feature'. I'm not sure where that
came from.
Personally I think having to insert a cast makes the code more
error-prone. The cure is worse than the disease.
Consider also that with the original code, the compiler could install
debug-time asserts on any such narrowing conversion. Once you insert a
cast, that's impossible, since the language doesn't distinguish between
(a) 'I know that is OK' casts, (b) 'I want to pretend that this is a
different type' casts, and (c) 'I want you to change this into another
type' casts.
Compiler checks should only be inserted for case (a) and (c).
