[5.9] Add support for an externally defined block list configuration file #66688
Conversation
An example of this format is:
---
actionToTakeFor:
ModuleName:
- moduleName1
ProjectName:
- projectName1
…e verification errors to warnings
…n't given by swift-driver Although swift-driver always passes down these blocklist for the compiler to consume, some frontend tools, like ABI checker, are invoked by the build system directly. Therefore, we need to teach the compiler to infer these blocklist files like prebuilt module cache.
|
@swift-ci please test |
xymus
left a comment
xymus
left a comment
There was a problem hiding this comment.
This will be very useful. None of my comments are blocking.
| return nullptr; | ||
| } | ||
| } | ||
| static std::string getScalaString(llvm::yaml::Node *N) { |
| F != FE; F.increment(EC)) { | ||
| StringRef ext = llvm::sys::path::extension(F->path()); | ||
| if (ext == "yml" || ext == "yaml") { | ||
| LangOpts.BlocklistConfigFilePaths.push_back(F->path()); |
There was a problem hiding this comment.
What's the main advantage of supporting many blocklists like this? My first though would be that one blocklist would be enough, unless we want different owners of each blocklist?
There was a problem hiding this comment.
Thank you for taking a look! The reasons for supporting multiple block lists are that (1) one single file may get too long over time, and (2) we could group similar actions into a single block list file, such as module loading related actions.
|
|
||
| BLOCKLIST_ACTION(ShouldUseBinaryModule) | ||
| BLOCKLIST_ACTION(ShouldUseTextualModule) | ||
| BLOCKLIST_ACTION(DowngradeInterfaceVerificationFailure) |
There was a problem hiding this comment.
Do I understand correctly that only DowngradeInterfaceVerificationFailure is enforced by this PR, and not ShouldUseBinaryModule nor ShouldUseTextualModule?
There was a problem hiding this comment.
Right. I suspect honoring ShouldUseBinaryModule and ShouldUseTextualModule here may cause a later merge conflict.
…building context and command lines
|
@swift-ci please test |
cherry-picks:
-- Basics: add a stub for centralized configurations for block list #64943
-- Basics: define a YAML-based blocklist format #65009
-- Frontend: pass down blocklist file paths from frontend options. NFC #65024
-- ModuleInterface: pass down block list file paths to module interface building context and command lines #65031
-- ModuleInterface: add a block list action to downgrade module interface verification errors to warnings #65033
-- Frontend: infer default blocklists to use when the explicit paths aren't given by swift-driver #65072
Explanation: These PRs add support for an externally defined block list to feed into the compiler. To avoid hard-coding module-specific behaviors in the compiler, we could skip rebuilding the compiler when the block list updates.
Scope: Module loading
Risk: Low
Reviewed by: @xymus