Re-enable assertions on macOS alt builds#146513
Conversation
|
@bors try |
Re-enable assertions on macOS try-job: `*apple*`
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
💔 Test for beeae75 failed: CI. Failed jobs:
|
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
Re-enable assertions on macOS try-job: `*apple*`
|
@bors try cancel |
|
Try build cancelled. Cancelled workflows: |
2bdfca2 to
b2c7b6b
Compare
|
@bors try |
Re-enable assertions on macOS try-job: `*apple*`
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
💔 Test for 56e5725 failed: CI. Failed jobs:
|
This wasn't caught by CI, because debug assertions aren't enabled there.
b2c7b6b to
25bedcd
Compare
|
So, I think this works! r? @Mark-Simulacrum since you're on t-infra and were assigned to #59637 in the past. Also CC @jieyouxu, since you've tried to do this in the past. |
|
I'm unsure if it has a performance impact, comparing it against the
Which feels like wayy too high a variance to really be able to say anything conclusive? |
|
This PR changes a file inside |
There was a problem hiding this comment.
I'm a bit confused. This appears to enable assertions on a bunch of dist targets, but distributed toolchains are not supposed to enable assertions.
Should this change be limited to only aarch64-apple, which is a test target and as such should enable assertions?
Right, the That said, it this will allow others to enable |
|
@bors r+ rollup=never This seems reasonable to me. Thanks! I agree that the CI times don't seem affected (at least within noise reasonable to achieve from a single PR's measurements). |
|
☀️ Test successful - checks-actions |
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 c8905ea (parent) -> f957826 (this PR) Test differencesShow 35 test diffsStage 2
Additionally, 3 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard f957826bff7a68b267ce75b1ea56352aed0cca0a --output-dir test-dashboardAnd 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 (f957826): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.0%, secondary 2.4%)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: 470.874s -> 470.189s (-0.15%) |
|
Okay, so this did change the timings fairly significantly:
Is this within an acceptable threshold? Or should we revert this? Or maybe split the |
|
That result is probably not representative, as this change will have triggered an uncached LLVM rebuild. |
|
Re perf regression, I think that's spurious, this is only affecting the macOS runners, which aren't perf-tested, and it shouldn't affect the |
These were previously disabled, in part for performance reasons, in part due to needing availability symbols
__isPlatformVersionAtLeastand__isOSVersionAtLeastthatcompiler-builtinsdid not provide, see #62592 (comment) and #134275 (comment) for failed checks.Since #138944 though,
stdnow provides these symbols, so we should be able to re-enable LLVM assertions, debug assertions and overflow checks.Fixes #59637.
try-job:
*apple*