What ways are there to determine if cascading compile errors are dependent or independent?

Question

In my experience as a developer, a single syntax error made in a long program can result in a long cascading list of error messages, only the first of which is directly relevant to the solution. For example, consider the following malformed C# program:

namespace Spaaaaaace
{
    public static class RequiredTestProtocol
    {
        public static void Test()
        {
            Console.WriteLine("As part of a required test protocol, we must run this program successfully.");
        // MISSING CLOSE BRACE
    
        public static void Main(string[] args)
        {
            Test();
        }

    }

}

When I attempt to compile this program, I not only see the error about the missing close brace, but an additional message about how declaring public members within a function is not allowed, which is something I never intended to do. This additional message is solely a result of my initial error and has nothing to do with any error I made in my Main function.

On the other hand, it is entirely possible for a programmer to make multiple, independent compile-time errors within one program under circumstances in which the programmer might want to know about each instance. An example could be declaring multiple for loops, each of which is malformed.

Are there ways to differentiate each of these cases at compile time? That is, if a compiler has decided that there are multiple compile errors to report, is there a way for it to determine whether these are all independent errors or whether some or all of the later errors would be fixed by fixing an earlier error, and then reporting only the "real" errors?

Answer 1

I don't know how this could be prevented entirely, but there are some mitigation ideas.

Simply ignore successive errors

When parsing fails a lot of tokens in sequence are not going to make sense leading to a lot of errors. One option is to suppress successive errors. Only if there is a "gap" in the errors, which would indicate the parser has found it's footing again, show more errors.

This way multiple errors in a file can be shown properly as long as the are sufficiently far apart.

Forcibly switching context

When encountering a token that doesn't make sense in the current context, for example a public function inside a method, switch the parser context to whatever place a public would be OK. This works well for keywords that only really make sense in one place like a class body, but if something can appear in multiple places and you guess wrong what context to switch you it could lead to even more incomprehensible errors.

Using the indentation as a hint

In languages with {} style code blocks parsers shouldn't really look at indention, but what if it did.

In case of a parsing error the parser can look for the nearest indent or dedent missing any kind of brace or parenthesis and insert a opening or closing brace/bracket/parenthesis there. If the code makes sense now they can give a much clearer hint about what the programmer should do while also being able to properly parse and print errors for the rest of the file.

This will fail if the code is not indented properly, or a indentation style is used the compiler doesn't recognize.

Answer 2

The problem with missing close braces is that the compiler can't know whether the errors are indeed dependent or independent. The only clues that you didn't intend to write the below code and truly made two mistakes are things that can only be understood by humans not computers:

namespace Spaaaaaace
{
    public static class RequiredTestProtocol
    {
        public static void Test()
        {
            Console.WriteLine("As part of a required test protocol, we must run this program successfully.");
    
            static void Main(string[] args)
            {
                Test();
            }
        }
    }
}

It would be possible to have a hierarchy of syntax errors and only report errors high-up on the hierarchy if there are no errors lower-down on the hierarchy (with unbalanced brackets being below everything else), in which case the two for loop errors would likely be on the same level, but this can't be done in the general case.