digitalmars.D.bugs - [Issue 2464] New: Correct error message causes incorrect error messages
- d-bugmail puremagic.com (48/48) Nov 19 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2464
- d-bugmail puremagic.com (11/11) Nov 20 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2464
- d-bugmail puremagic.com (11/11) Nov 20 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2464
- d-bugmail puremagic.com (7/7) Nov 20 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2464
- d-bugmail puremagic.com (34/34) Nov 20 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2464
- d-bugmail puremagic.com (18/18) Nov 20 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2464
- d-bugmail puremagic.com (15/15) Nov 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=2464
http://d.puremagic.com/issues/show_bug.cgi?id=2464 Summary: Correct error message causes incorrect error messages Product: D Version: 1.033 Platform: PC OS/Version: Windows Status: NEW Severity: minor Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: jminer2613 students.pcci.edu This bug I have seen many times. The following block of code has a clear error: it refers to the variable k that does not exist. The compiler correctly reports that error. However, when it reports the error in line 8, it also reports 5 more errors, even though there are no other errors. The compiler will report no errors if the k is changed to j on line 8. This not only happens with an undefined identifier error; many other errors cause the same problem. (trying to concatenate two numbers, leaving out the comma in a foreach, using the wrong type in a with statement, using = in an if statement, etc.) If you use a few void-inferred delegates and misspell one variable name, the compiler can spew out 50 lines of incorrect error messages. This problem causes me to compile, fix the first error message, compile again, fix the first, ... when there are multiple errors. -----errors.d----- char[] concat(char[] x, char[] y) { return x ~ y; } void delegate() foo; void func() { int j = 5; k = 6; foo = () { }; mixin(concat("j = ", "7;")); } ----- errors.d(8): Error: undefined identifier k errors.d(10): Error: cannot implicitly convert expression (__dgliteral1) of type int delegate() to void delegate() errors.d(13): Error: cannot evaluate concat("j = ","7;") at compile time errors.d(13): Error: argument to mixin must be a string, not (concat("j = ","7;")) errors.d(13): Error: cannot evaluate concat("j = ","7;") at compile time errors.d(13): Error: argument to mixin must be a string, not (concat("j = ","7;")) --
Nov 19 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2464 2korden gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |enhancement Well, this isn't a bug really. Compiler internals might be messed up by the time it finds and reports an error and sometimes it is hard to recover from them. Marking it as an enhancement. --
Nov 20 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2464 This isn't a matter of compiler internals being messed up -- this is consistent and, I believe, deliberate behavior. Unusual, but useful once you're used to it. Inserting a default type for a previously undefined variable allows the compiler to continue on and maybe find more errors. It will also result in bad error messages. It should be possible to give a default type of "unknown" that accepts any sort of variable assignment and any sort of field or method access, or else complains about all usages. --
Nov 20 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2464 Currently DMD gives an error type in this cases, which is just an alias to int. It would be nice if it were a type that acted as an int, or anything else, but didn't produce subsequent errors. I don't find a cascade of errors useful at all. Normally you are just interested in the root cause. --
Nov 20 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2464 why the compiler reports extra errors on code that uses a previously undefined variable: char[] str = "Hello"; char[] func() { return strr; } ----- errors.d(2): Error: undefined identifier strr errors.d(2): Error: cannot implicitly convert expression (strr) of type int to char[] Currently, the compiler uses int for the undefined variable and reports an extra error. This could be fixed as was mentioned (and I'd like that), but is more understandable. But I think this issue is separate. The example code I showed has an unrelated delegate that does not use an undefined variable. The following is a similar test case. Why would referencing an undefined variable in func() cause the comipler to think the delegate in func2() returns an int? void func() { char[] j = "hi"; k = "there"; } void delegate() foo; void func2() { foo = () { }; } ----- errors.d(3): Error: undefined identifier k errors.d(3): Error: cannot implicitly convert expression ("there") of type char[5u] to int errors.d(8): Error: cannot implicitly convert expression (__dgliteral1) of type int delegate() to void delegate() --
Nov 20 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2464 Ah, right. I see that in FuncExp::semantic there's: --- if (global.errors) { if (!fd->type->next) fd->type->next = Type::terror; } --- Which basically says "If there was a previous error, don't infer the type of the delegate and just set it to return error (well, int)". There are many checks like this, "If there weren't errors, go on, else, quit fast". That's because if it wouldn't be like that, you'll get even more errors than now. :-P But if errors didn't cause other errors, I believe all these checks could be removed. --
Nov 20 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2464 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |clugdbug yahoo.com.au Resolution| |DUPLICATE The general issue was fixed in 2.047 and 1.062, as part of bug 4266. A few cases remain where _error appears, instead of being suppressed: that's is bug 4329. *** This issue has been marked as a duplicate of issue 4329 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 05 2010