Replay the tip package's lib target when hot-patching a lib+bin package - #5779
Open
pauldemarco wants to merge 1 commit into
Open
Replay the tip package's lib target when hot-patching a lib+bin package#5779pauldemarco wants to merge 1 commit into
pauldemarco wants to merge 1 commit into
Conversation
The tip package is excluded from the workspace hotpatch replay on the
theory that cargo_build compiles it separately. That covers the bin
target, but when the tip also has a lib target (src/lib.rs + a thin
src/main.rs), the lib is consumed as an rlib and never replayed: the
replay set comes back empty, workspace_hotpatch_link_rlibs contributes
nothing, and the patch is linked from the bin's unchanged objects. The
result is an empty patch that reports success, so edits to lib code
silently never apply.
Make the tip eligible for replay when the captured rustc args contain a
{tip}.lib entry. workspace_hotpatch_replay_args already prefers the .lib
key, and the topo sort handles the tip node since nothing in the
workspace depends on it.
This restores what DioxusLabs#5291 added for DioxusLabs#4160; the compile_workspace_deps
path that handled lib+bin tips was removed in the DioxusLabs#5479 refactor.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fixes #5778.
When the tip package has both a
[lib]and a[[bin]], edits to lib code produce an empty patch that reports success:workspace_hotpatch_replay_orderexcludes the tip package from the replay set,cargo_buildonly contributes the bin unit's objects, and the lib rlib never reaches the patch link. Full mechanism and the regression history (#4160 implemented by #5291, removed in the #5479 refactor) are in the issue.The change makes the tip eligible for replay exactly when the captured rustc args contain a
{tip}.libentry. Gating on the captured args rather than the manifest means eligibility uses the same key the replay and rlib lookups will ask for.workspace_hotpatch_replay_argsalready prefers{crate}.libover{crate}.bin, and the topo sort handles the tip node since nothing in the workspace depends on it.Tested against a real lib+bin workspace (bevy app, ~45k lines in the lib, thin
main.rs):replaying crates: [], patch.sowith ~1,900 symbols, none from the app; edits never apply while the CLI logs successreplaying crates: ["myapp"], ~127,000 symbols including the edited functions by name, edits apply in about 2s, repeatedly, and reverting the edit patches backBin-only tips are unaffected:
tip_has_libis false when no{tip}.libargs were captured, so the filter behaves exactly as before.