Add HEADER_DEPENDENCIES build setting with validation #706
Conversation
bob-wilson
requested review from
aciidgh,
jakepetroules,
mirza-garibovic,
mhrawdon,
neonichu and
owenv
as code owners
|
@swift-ci test |
I am bringing back the need for this in #703 to emit per-task diagnostics in the |
|
@swift-ci test macOS |
1 similar comment
|
@swift-ci test macOS |
bob-wilson
force-pushed
the
bwilson/header-dependency-validation
branch
from
e659f44 to
e74a2ba
Compare
|
@swift-ci test |
| @@ -81,6 +81,6 @@ struct UniversalPlatformTaskProducerExtension: TaskProducerExtension { | |||
|
|
|||
| struct UniversalPlatformTaskActionExtension: TaskActionExtension { | |||
| var taskActionImplementations: [SWBUtil.SerializableTypeCode : any SWBUtil.PolymorphicSerializable.Type] { | |||
| [41: TestEntryPointGenerationTaskAction.self] | |||
| [44: TestEntryPointGenerationTaskAction.self] | |||
There was a problem hiding this comment.
@owenv The value of 41 was previously one higher than the largest type code in BuiltinTaskActionsExtension. I've increased it by 3 to account for the 1 new task action added here plus the 2 others that you just added. This seems fragile, though. If the intent is for it to have a unique code here, maybe we should put a placeholder in BuiltinTaskActionsExtension to reserve a number for this? I don't really have any context on this, though.
|
@swift-ci test macOS |
This is similar to MODULE_DEPENDENCIES but for non-modular header file inclusion dependencies. Our approach to this has changed a bit over the last few months, and the trace output from Clang does not distinguish the modular vs. non-modular includes. We will work on fixing that, but in the meantime, this continues the placeholder approach used for MODULE_DEPENDENCIES where it assumes anything in a framework has a module with the same name as the framework. This also removes moduleDependenciesContext from ClangTaskPayload because the code that needs that now gets it from ValidateDependenciesPayload. rdar://150309197
bob-wilson
force-pushed
the
bwilson/header-dependency-validation
branch
from
e74a2ba to
8063c53
Compare
|
One of the WatchBuildOperationTests was failing because of a new warning. The test uses |
|
@swift-ci test |
This is similar to MODULE_DEPENDENCIES but for non-modular header file inclusion dependencies. Our approach to this has changed a bit over the last few months, and the trace output from Clang does not distinguish the modular vs. non-modular includes. We will work on fixing that, but in the meantime, this continues the placeholder approach used for MODULE_DEPENDENCIES where it assumes anything in a framework has a module with the same name as the framework.
This also removes moduleDependenciesContext from ClangTaskPayload because the code that needs that now gets it from ValidateDependenciesPayload.
rdar://150309197