This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix crash in AccessDeclContextSanity when copying FunctionTemplateDecl inside a record.
ClosedPublic

Authored by teemperor on Dec 26 2019, 9:25 AM.

Details

Summary

We currently don't set access specifiers for function template declarations. This seems to be fine
as long as the function template is not declared inside any record in which case Clang asserts
with the following once we try to query it's access:

Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function AccessDeclContextSanity,

This patch just marks these function template declarations as public to make Clang happy.

Diff Detail

Event Timeline

teemperor created this revision.Dec 26 2019, 9:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 26 2019, 9:25 AM
teemperor retitled this revision from [lldb] Fixcrash in AccessDeclContextSanity when copying FunctionTemplateDecl inside a record. to [lldb] Fix crash in AccessDeclContextSanity when copying FunctionTemplateDecl inside a record..Dec 26 2019, 9:25 AM
  • Add unit test.

I'll land this now as its a pretty straightforward fix.

teemperor accepted this revision.Jan 2 2020, 5:45 AM
This revision is now accepted and ready to land.Jan 2 2020, 5:45 AM
This revision was automatically updated to reflect the committed changes.
shafik added inline comments.Jan 2 2020, 1:39 PM
lldb/source/Symbol/ClangASTContext.cpp
1347

Where is the method being added and why are we not setting the access there? Are we creating it though CreateFunctionTemplateDecl should be be checking the DeclContext there to see if it is a RecordDecl?

teemperor marked an inline comment as done.Jan 3 2020, 4:51 AM
teemperor added inline comments.
lldb/source/Symbol/ClangASTContext.cpp
1347

We actually don't add it anywhere but instead use an already created related FunctionDecl and set this FunctionTemplateDecl as its specialisation (see lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:1216).

We could also add the FunctionTemplateDecl to the DeclContext explicitly. That doesn't seem to break anything and seems consistent with the other functions for creating Decls. On the other hand I'm not sure if this is is some untested workaround for something.

But in any case, whatever we returned from this function (or whether it was added to the DeclContext) is in an invalid state that triggers an assert as soon as anyone calls getAccess on it.

shafik added inline comments.Jan 3 2020, 10:46 AM
lldb/source/Symbol/ClangASTContext.cpp
1347

Right so b/c this is a templated class member function we have a large comment above this check in DWARFASTParserClang.cpp:

if (is_cxx_method && has_template_params)

explaining why it is not added as a C++ method, which means we don't add this via m_ast.AddMethodToCXXRecordType(...) which would get the access specifiers set at all.

I feel like we should handle this in DWARFASTParserClang.cpp around line 1216 and get the access specifier correct instead of hack where we just set it to public.