[cfe-dev] Marking declarations as invalid

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Thu Nov 5 15:56:26 PST 2015


On Thu, Nov 5, 2015 at 3:40 PM, Nathan Wilson <nwilson20 at gmail.com> wrote:

> On Nov 5, 2015 5:18 PM, "Richard Smith" <richard at metafoo.co.uk> wrote:
> >
> > On Thu, Oct 29, 2015 at 8:04 PM, Nathan Wilson via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> Would someone mind explaining when (or when not) to mark a declaration,
> i.e. FunctionDecl or VarDecl, an invalid declaration?
> >>
> >> Then, if the declaration is marked invalid, at what do we look at/use
> that information?
> >
> > Here are some guidelines:
> >
> >   * You must not mark a declaration as invalid unless you have emitted
> an error.
> >   * If you emitted an error with a fix-it hint, you should not mark the
> declaration as invalid (and you should recover as if the fix-it hint were
> applied). We would like this to be a hard rule, but there are existing
> cases where we don't follow this.
> >   * You should mark a declaration as invalid if you think it's
> sufficiently far from the user's intent that follow-on diagnostics should
> be suppressed.
> >   * You must mark a declaration as invalid if it does not correspond to
> anything like a valid declaration (if it would be unreasonable to expect
> downstream code to do the right thing with it).
>
> Thanks for this Richard. That helps a lot.
>
> So, I could (should?) have used a fix-it hint in the example above and not
> mark the declaration invalid, correct? (Aside from your third bullet.)
>
Ah, well... you should only put a fix-it hint on an error when you are
extremely confident you know what the user did wrong. People find it very
frustrating when we incorrectly guess what they did wrong, and then produce
follow-on diagnostics about our bad guess.

> Would you be able to give an example of the fourth bullet and/or point to
> where the downstream code would do the right thing?
>
A variable with type 'void', or a redeclaration of a variable with a
different type. You can think about it this way: when you're writing code
that looks at an AST node, it's reasonable for you to assume that the AST
node corresponds to some part of the underlying language (unless it's
marked as invalid), so you don't need to re-check properties that the
language itself guarantees (such as, all declarations of a function have a
type that is in fact a function type). And this puts a requirement on code
that creates AST nodes, to mark them as invalid if it cannot satisfy that
assumption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151105/2ac48677/attachment.html>


More information about the cfe-dev mailing list