Repository navigation
refactor: Hot reload's compiled-caller analysis sits behind one entry point in its own assembly, and a run's wait for a background read is now timed - #3273
Merged
Conversation
Contributor
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
⛔ Files ignored due to path filters (24)
📒 Files selected for processing (57)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
Summary
warm_up_yield.This merges the integration branch
refactor/hot-reload-compiled-callers:HotReloadCompiledCallersand the run scopeHotReloadCompiledCallersRun. The orchestrator, the composition root, the warm-up items, the Editor hooks, the signature-change gate and the run accumulator now go through them instead of using the parts directly. Building the one-shot notes is split from attaching them to the run's outcomes. The run's start order is fixed (below), and boundary tests are added for the entry point.UnityCLILoop.FirstPartyTools.HotReload.CompiledCallers.Editor. Only the entry point, the run scope and the types they take and return are public, and the members hot reload does not read stay internal. The new assembly opens its internals only to the hot-reload tests, never to the hot-reload application assembly. This PR only moves files and changes modifiers.User Impact
warm_up_yield, and only then takes the hold, so the wait shows up in that step.Changes
Verification
uloop compileafter each commit: 0 errors, only pre-existing warnings.uloop compile: 0 errors, every warning pre-existing.OnionAssemblyDependencyTestspasses 83/83.d90045d9: the full EditMode suite passed on every leg (Unity 2022.3.62f3, 6000.3.15f1, 6000.5.8f1 and the latest 6000.7, the Release code-optimization leg, and the concurrency unit tests; https://github.com/hatayama/unity-cli-loop/actions/runs/38056480707). Compile Check passed on 2022.3.62f1 and 6000.5.4f1.warm_up_yield(560 ms, against a 557 ms gap between the run's start and the read's end), and the run's unaccounted time fell from 560 ms to 6 ms. The budget, the refused assemblies, the background reads, the outcomes and the notes matched the previous round. No cache eviction, and no error or exception in the Console during the check.