[Explicit Module Builds][Incremental Builds] Re-compile module dependencies whose dependencies are up-to-date themselves but are themselves newer #1628
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
artemcm
changed the title
artemcm
force-pushed
the
ReCompileDepsWithNewerUpToDateDeps
branch
3 times, most recently
from
262a20b to
28f6b63
Compare
owenv
reviewed
Jun 7, 2024
Sources/SwiftDriver/IncrementalCompilation/FirstWaveComputer.swift
Outdated
Show resolved
Hide resolved
artemcm
force-pushed
the
ReCompileDepsWithNewerUpToDateDeps
branch
from
28f6b63 to
bc16bd6
Compare
…necies whose dependencies are up-to-date themselves but are themselves newer
For example consider the following module graph:
test
\
J
\
G
Where on an incremental build we detect that although G binary module product is *newer* than its textual source, said binary module product is also *newer* than a prior binary module product of J. Which means that although each of the modules is up-to-date with respect to its own textual source inputs, J's binary dependnecy input has been updated elsewhere and J needs to be re-built.
Resolves rdar://129225956
artemcm
force-pushed
the
ReCompileDepsWithNewerUpToDateDeps
branch
from
bc16bd6 to
adce133
Compare
…extension on the graph itself
artemcm
force-pushed
the
ReCompileDepsWithNewerUpToDateDeps
branch
from
c1f3040 to
3bbdc0e
Compare
|
@swift-ci test |
…k if a prior inter-module dep graph is up-to-date with a check to decide which modules to re-build Using the same 'computeInvalidatedModuleDependencies' routine, which is more thorough and checks module inputs to each dependency as well.
artemcm
force-pushed
the
ReCompileDepsWithNewerUpToDateDeps
branch
from
3bbdc0e to
3be4396
Compare
|
@swift-ci test |
owenv
approved these changes
Jun 7, 2024
|
@swift-ci test Windows platform |
This was referenced Jun 11, 2024
artemcm
added a commit
to artemcm/swift-driver
that referenced
this pull request
Jul 30, 2024
…module dependencies as up-to-date Instead of conservatively assuming them to be new/updated in order to invalidate their dependents. This behavior is no longer necessary since the implementation of swiftlang#1628 (adce133) which will ensure that if a binary module dependnecy is newer than any of its dependents they will get invalidated and re-built.
artemcm
added a commit
to artemcm/swift-driver
that referenced
this pull request
Jul 30, 2024
…module dependencies as up-to-date Instead of conservatively assuming them to be new/updated in order to invalidate their dependents. This behavior is no longer necessary since the implementation of swiftlang#1628 (adce133) which will ensure that if a binary module dependnecy is newer than any of its dependents they will get invalidated and re-built.
artemcm
added a commit
to artemcm/swift-driver
that referenced
this pull request
Jul 30, 2024
…module dependencies as up-to-date Instead of conservatively assuming them to be new/updated in order to invalidate their dependents. This behavior is no longer necessary since the implementation of swiftlang#1628 (adce133) which will ensure that if a binary module dependnecy is newer than any of its dependents they will get invalidated and re-built.
artemcm
added a commit
to artemcm/swift-driver
that referenced
this pull request
Jul 31, 2024
…module dependencies as up-to-date Instead of conservatively assuming them to be new/updated in order to invalidate their dependents. This behavior is no longer necessary since the implementation of swiftlang#1628 (adce133) which will ensure that if a binary module dependnecy is newer than any of its dependents they will get invalidated and re-built.
artemcm
added a commit
that referenced
this pull request
Jul 31, 2024
…module dependencies as up-to-date Instead of conservatively assuming them to be new/updated in order to invalidate their dependents. This behavior is no longer necessary since the implementation of #1628 (adce133) which will ensure that if a binary module dependnecy is newer than any of its dependents they will get invalidated and re-built.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For example consider the following module graph:
graph LR; test-->J; J-->G;Where on an incremental build we detect that although
Gbinary module product is newer than its textual source, said binary module product is also newer than a prior binary module product ofJ. Which means that although each of the modules is up-to-date with respect to its own textual source inputs,J's module dependency's binary input has been updated elsewhere andJneeds to be re-built.Resolves rdar://129225956