Skip to content

[SymbolGraph] don't scan every available module for cross-import overlays #36303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 8, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 13 additions & 12 deletions tools/driver/swift_symbolgraph_extract_main.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -217,12 +217,13 @@ int swift_symbolgraph_extract_main(ArrayRef<const char *> Args, const char *Argv
}

auto M = CI.getASTContext().getModuleByName(options::ModuleName);
SmallVector<Identifier, 32> VisibleModuleNames;
CI.getASTContext().getVisibleTopLevelModuleNames(VisibleModuleNames);
if (!M) {
llvm::errs()
<< "Couldn't load module '" << options::ModuleName << '\''
<< " in the current SDK and search paths.\n";

SmallVector<Identifier, 32> VisibleModuleNames;
CI.getASTContext().getVisibleTopLevelModuleNames(VisibleModuleNames);

if (VisibleModuleNames.empty()) {
llvm::errs() << "Could not find any modules.\n";
Expand Down Expand Up @@ -260,16 +261,16 @@ int swift_symbolgraph_extract_main(ArrayRef<const char *> Args, const char *Argv
// don't need to print these errors.
CI.removeDiagnosticConsumer(&DiagPrinter);

for (const auto &ModuleName : VisibleModuleNames) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need to accumulate the VisibleModuleNames above? Maybe we should log what findDeclaredCrossImportOverlaysTransitive returns?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for logging, since we're printing the modules as we load them, i don't think it's 100% necessary to add more logging on top of that just to list the modules beforehand.

if (ModuleName.str().startswith("_")) {
auto CIM = CI.getASTContext().getModuleByName(ModuleName.str());
if (CIM && CIM->isCrossImportOverlayOf(M)) {
const auto &CIMainFile = CIM->getMainFile(FileUnitKind::SerializedAST);
llvm::errs() << "Emitting symbol graph for cross-import overlay module file: "
<< CIMainFile.getModuleDefiningPath() << '\n';

Success |= symbolgraphgen::emitSymbolGraphForModule(CIM, Options);
}
SmallVector<ModuleDecl *> Overlays;
M->findDeclaredCrossImportOverlaysTransitive(Overlays);
for (const auto *OM : Overlays) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we used to sort the overlays by name. Is this something we should do here as well? I'm not sure whether sorting was a requirement for us to produce correct SGFs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original use for VisibleModuleNames is for reporting to the user when the given module name wasn't found. The sorting was (as far as i know) just for ease of user experience when reading the module list. I can move the initialization and sorting back into that error branch so we don't hit that in the normal path at all.

auto CIM = CI.getASTContext().getModuleByName(OM->getNameStr());
if (CIM) {
const auto &CIMainFile = CIM->getMainFile(FileUnitKind::SerializedAST);
llvm::errs() << "Emitting symbol graph for cross-import overlay module file: "
<< CIMainFile.getModuleDefiningPath() << '\n';

Success |= symbolgraphgen::emitSymbolGraphForModule(CIM, Options);
}
}

Expand Down