Skip to content

DependencyScanner: honor additional compiler flags in interfaces files when collecting imports #31553

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 2 commits into from
May 5, 2020

Conversation

nkcsgexi
Copy link
Contributor

@nkcsgexi nkcsgexi commented May 5, 2020

Additional flags in interface files may change parsing behavior like #if
statements. We should use a fresh ASTContext with these additional
flags when parsing interface files to collect imports.

rdar://62612027

…s when collecting imports

Additional flags in interface files may change parsing behavior like #if
statements. We should use a fresh ASTContext with these additional
flags when parsing interface files to collect imports.

rdar://62612027
@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented May 5, 2020

@swift-ci please smoke test

@nkcsgexi nkcsgexi requested a review from DougGregor May 5, 2020 14:43
…compiler instance for interface scanner. NFC
@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented May 5, 2020

@swift-ci please smoke test

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented May 5, 2020

@swift-ci please test asan

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented May 5, 2020

@swift-ci Please ASAN test

@nkcsgexi nkcsgexi merged commit 13cb4a4 into swiftlang:master May 5, 2020
@@ -58,13 +59,51 @@ static void findAllImportedClangModules(ASTContext &ctx, StringRef moduleName,
}
}

struct InterfaceSubASTContextDelegate: SubASTContextDelegate {
bool runInSubContext(ASTContext &ctx, StringRef interfacePath,
Copy link
Member

Choose a reason for hiding this comment

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

Much of this logic is also in ModuleInterfaceBuilder::buildSwiftModuleInternal, although some bits of validation there are missing here. Is there a way to unify this with buildSwiftModuleInternal? For example, by parameterizing it with an action like this function has, and having the dependency scanner's action be "walk the imports" and the module builder's action be "type check and serialialize"? More sharing there would help us avoid any discrepancies with the main build.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, it seems to be feasible. The configuration setup here is mostly for parsing to be performed correctly, which doesn't require options like SerializationOptions to be configured. We could potentially move these additional setups to the action body of "type check and serialize".

Copy link
Member

Choose a reason for hiding this comment

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

I'd certainly prefer that. Anything that differs between the fast dependency scanner and the normal build process is going to be a hard-to-diagnose bug later on down the line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants