www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2464] New: Correct error message causes incorrect error messages

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2464


2korden gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |enhancement




------- Comment #1 from 2korden gmail.com  2008-11-20 04:23 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2464





------- Comment #2 from dhasenan gmail.com  2008-11-20 18:22 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2464





------- Comment #3 from ary esperanto.org.ar  2008-11-20 18:30 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2464





------- Comment #4 from jminer2613 students.pcci.edu  2008-11-20 20:04 -------
re: #2 and #3: Good points, but this issue seems different to me. I understand
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2464





------- Comment #5 from ary esperanto.org.ar  2008-11-20 20:37 -------
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
prev sibling parent d-bugmail puremagic.com writes:
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


--- Comment #6 from Don <clugdbug yahoo.com.au> 2010-11-05 01:22:40 PDT ---
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