Page MenuHomePhabricator

[SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.
ClosedPublic

Authored by zturner on Jan 10 2019, 3:00 PM.

Details

Summary
Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many others, and by passing such a monolithic parameter
in this way it makes the requirements and assumptions of the
API unclear for both callers as well as implementors.

All these methods need is a CompileUnit.  By limiting the
parameter type in this way, we simplify the code as well as
make it self-documenting for both implementers and users.

This patch changes the following methods:
    * ParseCompileUnitLanguage(const SymbolContext&)
    * ParseCompileUnitFunctions(const SymbolContext&)
    * ParseCompileUnitLineTable(const SymbolContext&)
    * ParseCompileUnitDebugMacros(const SymbolContext&)
    * ParseCompileUnitSupportFiles(const SymbolContext&)
    * ParseTypesForCompileUnit(const SymbolContext&)

to accept only a CompileUnit&, which is both necessary and
sufficient for them to complete their task.

Note that this is purely mechanical, so it's not necessary to review the whole patch in detail unless you really want to. The main change can be viewed in the first file.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

zturner created this revision.Jan 10 2019, 3:00 PM
zturner retitled this revision from [SymbolFile] to [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&..

All the change to the symbol vendor make sense, but it seems like all of the call sites should be:

cu->GetLanguage();
cu->ParseFunctions();
cu->GetLineTable();
cu->ParseDebugMacros();
cu->GetSupportFiles();
cu->ParseTypes();

Some of these calls might already be there, but is seems like we should initiate these calls from the CompileUnit class.

lldb/source/Core/Module.cpp
373 ↗(On Diff #181166)

Seems like this should almost be:

sc.comp_unit->ParseAllFunctions()

Inside the compile unit it can pass "*this" to the symbol vendor?

All the change to the symbol vendor make sense, but it seems like all of the call sites should be:

cu->GetLanguage();
cu->ParseFunctions();
cu->GetLineTable();
cu->ParseDebugMacros();
cu->GetSupportFiles();
cu->ParseTypes();

Some of these calls might already be there, but is seems like we should initiate these calls from the CompileUnit class.

Some functions like that exist today (e.g. cu->GetLineTable(), cu->GetSupportFiles(), etc), but some don't (e.g. cu->GetFunctions() and cu->GetTypes() don't exist). I agree it would be nice to have the CompileUnit support all of these, but it might not be purely NFC, or at least it might be easy to accidentally make it *not* be NFC, because we'd be adding some member variables to the CompileUnit class for the laziness, to make the implementations match up with the implementation of the existing ones. Do you think it would be reasonable to start with this patch, which is definitely NFC, and then iterate on it to get more access to these things from the CompileUnit class directly?

clayborg accepted this revision.Jan 10 2019, 4:43 PM

This is fine to start.

This revision is now accepted and ready to land.Jan 10 2019, 4:43 PM
labath accepted this revision.Jan 11 2019, 12:27 AM

looks good to me.

lldb/include/lldb/Symbol/SymbolFile.h
135 ↗(On Diff #181166)

You're not consistent in the namespace qualification of CompileUnit. I'd suggest removing the namespace qualification, since you're already in that namespace anyway...

This revision was automatically updated to reflect the committed changes.