Improve errors

[turbolent]

There are several ways in which the current developer experience could be improved:

• Improve error messages: Improve error messages #2050
• Not declared error / Invalid member access errors: suggest similar declarations and fields/functions
• Allow initial value and missing type for structure field in parser/AST, but reject in checker
• Return dedicated error when function has post-condition with result, and also local variable named result
• Return dedicated error when function has post-condition with before, and also local variable named before
• Allow structure conformances to be any type in grammar, but reject in checker
• Parse func, fn, and function and error suggesting to use fun
• Provide a dedicated error when whitespace is used in type
• Only warn when function requirement in interface is empty/has no conditions. Currently developers stop mentioning conditions because error is reported right when start ({}) is typed
• Allow for incomplete AST: add rules to grammar to capture incomplete program parts. See http://duriansoftware.com/joe/Constructing-human-grade-parsers.html
• Allow arbitrary nesting in grammar, but enforce correct usage and provide nice error messages when checking
• Provide a more helpful error when a function is named and rejected because it is named like an initializer or destructor (see Checker.checkMemberIdentifier)
• Recommend using remove when moving element out of a dictionary
• When using an array syntax like T[], suggest [T]

Each of these ideas/features is basically a separate issue.

Tasks:

• Improve error messages #2050

[dsainati1]

Paraphrasing a discussion from slack:

My general thoughts on this are that there is diminishing returns in working on improving error reporting. Once you reach a certain level of clarity, making the messages more clear is not going to improve anything because the users who are confused are just not reading them. Instead I think time and effort are better spent on fostering a community around debugging/solving errors in your language (StackOverflow, error FAQs on the docs, and generally more community resources for fixing/understanding broken code) and otherwise encouraging users to actually read the errors your language produces.

I think immediate points of improvement that Cadence could use to improve its errors is reporting the actual lines on which runtime errors occur, as well as giving the line numbers of references for type errors (e.g. if we have some error that says x.f is invalid because x has no member f, we should both report the line on which the invalid access occurs, as well as a pointer to where x was created or where its type was defined).

I also think error autofixes are particularly useful precisely because users do not read error messages; they allow users to fix their problems without reading the message, and are thus going to be more useful to them than any kind of improvement to the text of the errors themselves.