-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Rollup of 3 pull requests #147943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 3 pull requests #147943
Conversation
There are a few tests that were trying to skip i586 targets via the `TARGET` environment variable instead, so better to just add support for the directive.
If something like this is needed again in the future, please set environment variables for the build and run subprocesses, instead of setting them on the compiletest process.
Now that all directive names are checked against a list of known-good names, these ad-hoc checks can never fire.
compiletest: Don't set `TARGET` for non run-make tests There are a few tests that were using `TARGET` to quietly do nothing on `i586` targets, but it's cleaner to just add support for `//@ ignore-i586` instead. This lets us get rid of an unsafe `env::set_var` in compiletest, which really should have been setting the environment variable on individual build/run subprocess commands anyway. - The original code and tests were introduced way back in rust-lang#39068
motor: Add new `set_times` stubs Motor OS `std` support (rust-lang#147000) and `set_times`/`set_times_nofollow` (rust-lang#147468) were merged around the same time, so Motor OS is missing this API and currently fails to build. cc `@lasiotus`
compiletest: More directive handling tweaks - Follow-up to rust-lang#147903. --- These are some more preparatory changes that were extracted from a larger overhaul of directive handling that I'm still working on. --- The revision check was introduced by rust-lang#61778, and later modified by rust-lang#113603. It doesn't appear to be doing anything particularly load-bearing (since a bogus mode seems to cause a panic later anyway), and getting rid of it avoids the need to pass the current test revision to directive-handling code. - rust-lang#61778 - rust-lang#113603 r? jieyouxu
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 869fb4679f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 869fb46 (parent) -> 695857b (this PR) Test differencesShow 2 test diffs2 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 695857bc3f72ec4f59c79f323460fe488c38a53f --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (695857b): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (primary -2.1%, secondary 2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 474.127s -> 472.072s (-0.43%) |
Successful merges:
TARGET
for non run-make tests #147929 (compiletest: Don't setTARGET
for non run-make tests)set_times
stubs #147930 (motor: Add newset_times
stubs)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup