[PATCH] D65591: [AST] Add a flag indicating if any subexpression had errors

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.


================
Comment at: clang/include/clang/AST/DependenceFlags.h:46
     Instantiation = 2,
+    /// Placeholder, and is not used in actual Type.
+    Error = 4,
----------------
hokein wrote:
> sammccall wrote:
> > I'd like this comment to explain why it exists if not used in actual types.
> > 
> > Is this used for `decltype(some-error-expr)`? Is this used so toTypeDependence() returns something meaningful?
> > 
> > If this is used to make the bitcasting hacks work, we should just stop doing that.
> yeah, the main purpose of it is for convenient bitcast. AFAIK, we don't have a plan to use the error bit except in `Expr`. removing it for now.
> 
> 
I think we should plan to do this for Type too, though it's OK not to do so in this patch.

consider e.g. the expression `decltype(foo){}` where `foo` has errors. Today we're saying this has no errors, because the DeclTypeType node isn't error-dependent.

(This is true whether you add the enum value or not: the `Type` constructor takes a bunch of booleans in the constructor, it would need to be refactored to support `TypeDependence` and possibly the computeDependence pattern)

I think we should ensure that as far as possible, this code conceptually propagates error-dependence from types to expressions correctly, even if the error-dependence is not set in practice yet.
I'm not sure if this requires having the Error bit in `TypeDependence` now: if we never have to name it because we only blacklist bits, then it's probably OK.


================
Comment at: clang/lib/AST/ComputeDependence.cpp:124
   auto D = ExprDependence::None;
   if (E->getType()->isDependentType())
     D |= ExprDependence::Type;
----------------
we should be propagating more bits here:
 - error bit should be propagated from the type
 - type is already propagated
 - I think value/instantiation doesn't matter because if T is value/instantiation dependent we set both below
 - not sure why unexpanded-pack isn't propagated

so consider something like (unconditional)
```
// FIXME: why is unexpanded-pack not propagated?
D |= E->getType()->getDependence() & ~ExprDependence::UnexpandedPack
```


================
Comment at: clang/lib/AST/ComputeDependence.cpp:174
 ExprDependence clang::computeDependence(NoInitExpr *E) {
   return toExprDependence(E->getType()->getDependence()) &
          ExprDependence::Instantiation;
----------------
I'm not terribly sure of the implications of not propagating the error bit here. I tend to think that "contains errors" most closely follows instantiation-dependence (i.e. it's fairly strict/lexical), so I'd consider propagating it here.

BTW, DesignatedInitUpdateExpr seems to have totally broken dependence computations - it's always non-dependent! (Not introduced by this refactoring, I think). Any idea what's up there?


================
Comment at: clang/lib/AST/ComputeDependence.cpp:216
   auto D = turnTypeToValueDependence(E->getSubExpr()->getDependence());
   if (E->getType()->isDependentType())
     D |= ExprDependence::Type;
----------------
I believe if we're creating an initializer_list<T> and T has errors, then the expr should have errors


================
Comment at: clang/lib/AST/ComputeDependence.cpp:376
   auto *Decl = E->getDecl();
   auto Type = E->getType();
 
----------------
I think we're missing error propagation from `Type`.

(we could also consider a declrefexpr to an `invalid` decl to be an error...)


================
Comment at: clang/lib/AST/ComputeDependence.cpp:500
   if (E->isResultDependent())
     return D | ExprDependence::TypeValueInstantiation;
   return D | (E->getResultExpr()->getDependence() &
----------------
this should be D |=... so that result expr errors propagate


================
Comment at: clang/lib/AST/ComputeDependence.cpp:582
     Deps |= toExprDependence(Q->getDependence());
   for (auto *D : E->decls()) {
     if (D->getDeclContext()->isDependentContext() ||
----------------
(if we decide to make referring to an `invalid` decl an error, this is another spot... there are probably lots :-(. Deferring this is probably best)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65591/new/

https://reviews.llvm.org/D65591