Bug 1931 – dmd doesn't enforce users to use assert(0) for noreturn func

int k; bool setsomething() { if (k==4) return false; } void main() { } func setsomething should be banned because it not always returns bool in all flow.

this should be possibly a regression. And it's a very serious flow analysis problem.

Actually, the compiler inserts a HALT instruction at the other return, so you'll never see the function "fall off the end" and return garbage. This is as intended.

why not issue a compile error?

(In reply to comment #3) > why not issue a compile error? It does in very simple cases, like if there is only one code path. : noreturn.d(18): function noreturn.func expected to return a value of type int So what you are asking for is to improve the escape analysis to cover more cases. I think that's a hard problem in general. Also "regression" means something used to work in a previous release but now doesn't. But I don't think that's the case here. Did this ever work? If not this should technically be marked as "enhancement".

I really thought it were working :D I think I realize the problem now. sometimes people would intend to have a func without an extra return statement when all paths return. Barking with an error makes people frustrated. I hope if there's a way to specify this by some func qualifier. like: __built_in_no_return_check it shouldn't look clean.. if people really want the func to have that return statement optimized.

(In reply to comment #5) Doesn't assert(0) have this effect? You can put it in place of 'missing' return statements to tell the compiler that you know that control flow will never reach that location. http://www.digitalmars.com/d/2.0/expression.html#AssertExpression http://www.digitalmars.com/d/2.0/statement.html#ReturnStatement

Since we have assert(0); then we should deprecate the current compiler behavior. Every such piece code *should be* written as following: bool setsomething() { if (k==4) return false; assert(0); // developer should never ignore this line!! }

On 25/04/2008, [email protected] <[email protected]> wrote: > Every such piece code *should be* written as following: > bool setsomething() > { > if (k==4) > return false; > assert(0); // developer should never ignore this line!! > } Usefully, that's exactly what happens if you use the -w command line switch. I would certainly support raising this from a warning to an error. After being clobbered by this nasty crashing behavior once too often, I now /always/ compile with -w. But it pains me that every single D user* has to learn this lesson the hard way. ---- *or at least, every single /Windows/ D user. I'm told that falling off the end of a function on Linux is less crashy and more diagnostic than doing so on Windows, but not being a Linux user, I can't confirm that.

umm the bug have no longer got the meaning of the old title and keyword. let me fix it.

Technically, this _is_ an enhancement request. A major enhancement request IYO maybe, but still an enhancement request. The other severities are intended for bugs.

This was implemented in DMD2.031.