-
Notifications
You must be signed in to change notification settings - Fork 13.5k
std::vec
: Add UB check for set_len
, from_raw_parts_in
, and etc.
#143877
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
Conversation
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Let's make sure the compilation perf impact of this isn't atrocious: |
This comment has been minimized.
This comment has been minimized.
`std::vec`: Add UB check for `set_len`, `from_raw_parts_in`, and etc. Closes #143813 I noticed that `from_parts_in` do the similar things like `from_raw_parts_in`, so I add the UB check in the last commit. If it is not appropriate, I will remove it. And I fix a typo in the first commit. r? `@scottmcm`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Can you add tests that cover all the public APIs that are supposed to now detect misuse? Existing tests are here: https://github.com/rust-lang/rust/tree/master/tests/ui/precondition-checks I would expect tests to cover set_len, from_raw_parts, and from_raw_parts_in separately (so that we get a test failure if from_raw_parts gets implemented in a way that bypasses the check you're adding). If you know any other functions that trivially delegate to the checked code paths, those would be good to add too. I don't really care how you organize the new tests, anything that works and looks like the existing tests is good. |
Finished benchmarking commit (7219000): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never 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 0.3%, secondary -0.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.0%, secondary 2.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.2%, secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 463.69s -> 466.219s (0.55%) |
Seems acceptable. (the improvements are chaotic effects from perturbing the MIR inliner) |
Agreed. Results look neutral-ish and even if not obviously-green that's nowhere near the cataclysmic results we've seen from adding this in certain other cases, and the goal is just to avoid the "oh my" impacts for things like this. @bors r=scottmcm,saethlin |
`std::vec`: Add UB check for `set_len`, `from_raw_parts_in`, and etc. Closes #143813 I noticed that `from_parts_in` do the similar things like `from_raw_parts_in`, so I add the UB check in the last commit. If it is not appropriate, I will remove it. And I fix a typo in the first commit. r? `@scottmcm`
Oh, I haven't have time to add tests. Should I add it in a separate Pull Request? |
@bors r- |
I don't know why Scott put my approval on this without tests. I would prefer them here. |
☀️ Try build successful - checks-actions |
r? @saethlin |
…_in` Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
I added the tests in the new commit for @rustbot ready |
Tests are what I asked for, thanks. @bors r=scottmcm,saethlin |
☀️ 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 e27f16a (parent) -> 3014e79 (this PR) Test differencesShow 166 test diffsStage 1
Stage 2
Additionally, 156 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 3014e79f9c8d5510ea7b3a3b70d171d0948b1e96 --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 (3014e79): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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 -0.6%, secondary -2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 1.1%, secondary 3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.2%, secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 463.302s -> 465.928s (0.57%) |
Closes #143813
I noticed that
from_parts_in
do the similar things likefrom_raw_parts_in
, so I add the UB check in the last commit. If it is not appropriate, I will remove it.And I fix a typo in the first commit.
r? @scottmcm