Page MenuHomePhabricator

[lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers
ClosedPublic

Authored by teemperor on Fri, Feb 14, 5:18 AM.

Details

Summary

All of our lookup APIs either use CompilerDeclContext & or CompilerDeclContext * semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).

This moves all APIs to use references and gets rid of all the nullptr checks and conversions.

Diff Detail

Event Timeline

teemperor created this revision.Fri, Feb 14, 5:18 AM
labath accepted this revision.Fri, Feb 14, 5:25 AM

Yes, please.

Bonus points to anyone who can replace the default-constructed CompilerDeclContext with llvm::None.

This revision is now accepted and ready to land.Fri, Feb 14, 5:25 AM
shafik accepted this revision.Fri, Feb 14, 10:47 AM
shafik added a subscriber: shafik.

This is a great change, it makes the code more consistent. LGTM besides the few comments I made.

lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
1133–1134

!parent_decl_ctx.IsValid() && GetDeclContextContainingUID(result->getSymIndexId()) != parent_decl_ctx seems like a more accurate replacement especially if GetDeclContextContainingUID can also return an invalid result, I think.

1327–1328

Same comment as above.

1551–1552

same here.

teemperor marked an inline comment as done.Fri, Feb 14, 11:37 AM
teemperor added inline comments.
lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
1133–1134

I think the negation at the start is a typo? With the negation it would mean that with a valid parent_decl_ctx the continue would never be evaluated. But the intend seems to be to only parse variables that are in the DeclContext. So with the negation, specifying any parent_decl_ctxwould disable the filter and we would parse all variables in all DeclContexts?

But yeah, I think this makes sense. In theory DeclContextMatchesThisSymbolFile seems to early-exit on the error cases that would cause GetDeclContextContainingUID to return an invalid DeclContext and the function has an assert for an valid result at the end, but I think the IPDBSession error case could return an invalid DeclContext in this function. Let's just play safe and keep the check.

  • Readded some parent_decl_context.IsValid() checks to SymbolFilePDB
This revision was automatically updated to reflect the committed changes.