This is an archive of the discontinued LLVM Phabricator instance.

[clang] Use RecoveryExprs for broken defaultargs, instead of OpaqueValueExprs
ClosedPublic

Authored by kadircet on Aug 14 2023, 6:57 AM.

Details

Summary

This makes sure we can preserve invalid-ness for consumers of this
node, it prevents crashes. It also aligns better with rest of the places that
store invalid expressions.

Diff Detail

Event Timeline

kadircet created this revision.Aug 14 2023, 6:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 14 2023, 6:57 AM
Herald added a subscriber: arphaman. · View Herald Transcript
kadircet requested review of this revision.Aug 14 2023, 6:57 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 14 2023, 6:57 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
sammccall accepted this revision.Aug 14 2023, 7:10 AM

Nice, recoveryexpr is a better fit here. These changes tend to cause occasional new error-handling crashes on under-tested paths, but I guess it's a good time in the release cycle for that!

You might want a clangd or ast-dump test showing that we now preserve the internal structure of (some) invalid default initializes.

clang/include/clang/Sema/Sema.h
3026

nit: Nullable ExprResult* since there are only two states?
Extra get() in some callers, but less mysterious

clang/lib/Parse/ParseCXXInlineMethods.cpp
398

If this fixes the recursive copy-constructor case you mentioned, can you add a test?

(Else does it do anything? Or just cleanup)

400–401

DefArgResult is never anything here. I'd probably find /*DefaultArg=*/nullptr more obvious

clang/lib/Parse/ParseDecl.cpp
7562

Ditto

This revision is now accepted and ready to land.Aug 14 2023, 7:10 AM
kadircet updated this revision to Diff 549939.Aug 14 2023, 7:59 AM
kadircet marked 2 inline comments as done.
  • Use Expr* instead of ExprResult
  • Add dump test to demonstrate new RecoveryExpr
clang/include/clang/Sema/Sema.h
3026

i guess you meant Expr* ?

clang/lib/Parse/ParseCXXInlineMethods.cpp
398

no it doesn't. unfortunately that requires change in a separate code path to mark any method decls with invalid parmvardecls as invalid, which i'll try to put together. as that's the behavior for regular functiondecls, i don't see why it should be different for methods (if so we should probably change the behavior for functions instead).

400–401

maybe i am missing something, but "invalid" doesn't mean "unusable".

sammccall accepted this revision.Aug 14 2023, 1:10 PM

Still LG once you're happy

clang/include/clang/Sema/Sema.h
3026

Yes, sorry!

clang/lib/Parse/ParseCXXInlineMethods.cpp
400–401

ActionResult can be pointer-and-valid, null-and-valid, or null-and-invalid.

So invalid does indeed mean unusable ("usable" means pointer-and-valid).

Its documentation strongly suggests an ActionResult can be pointer-and-invalid, but good luck constructing one :-)

clang/test/AST/ast-dump-default-arg-recovery.cpp
7

Can you also check the contents (there should be a declrefexpr at least)?

Preserving this internal structure is important for clangd, the recoveryexpr alone doesn't help much.

This revision was landed with ongoing or failed builds.Aug 16 2023, 1:32 AM
This revision was automatically updated to reflect the committed changes.
kadircet marked 3 inline comments as done.