-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Detect and reject out-of-range integers in format string literals #102529
Conversation
Until now out-of-range integers in format string literals were silently ignored. They wrapped around to zero at usize::MAX, producing unexpected results. When using debug builds of rustc, such integers in format string literals even cause an 'attempt to add with overflow' panic in rustc. Fix this by producing an error diagnostic for integers in format string literals which do not fit into usize. Fixes rust-lang#102528
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wesleywiser (or someone else) soon. Please see the contribution instructions for more information. |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b9e85bf with merge 31cf317f4c1a3702d4c61fa903f29d9d9cb9477d... |
☀️ Try build successful - checks-actions |
Queued 31cf317f4c1a3702d4c61fa903f29d9d9cb9477d with parent 0265a3e, future comparison URL. |
Finished benchmarking commit (31cf317f4c1a3702d4c61fa903f29d9d9cb9477d): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The perf regressions are all in diesel which has been noisy lately. I also ran cachegrind locally and the changed function doesn't even appear in the perf diff.
It does seem quite odd to me that the size of the integers supported in the format string are tied to the host compiler's usize (ie, you could construct a program that compiles on a 64-bit compiler but fails with this error on a 32-bit compiler even though the --target
is the same). I think it would probably be better to just use a u64
instead of a usize
but I don't think that has to block landing this improvement over the current behavior.
I'm going to reassign to someone from T-libs so they can validate if they approve the doc change.
Thanks for the PR @colinba!
r? libs |
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ee1c3b3): 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. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
Detect and reject out-of-range integers in format string literals Until now out-of-range integers in format string literals were silently ignored. They wrapped around to zero at usize::MAX, producing unexpected results. When using debug builds of rustc, such integers in format string literals even cause an 'attempt to add with overflow' panic in rustc. Fix this by producing an error diagnostic for integers in format string literals which do not fit into usize. Fixes rust-lang#102528
Until now out-of-range integers in format string literals were silently ignored. They wrapped around to zero at usize::MAX, producing unexpected results.
When using debug builds of rustc, such integers in format string literals even cause an 'attempt to add with overflow' panic in rustc.
Fix this by producing an error diagnostic for integers in format string literals which do not fit into usize.
Fixes #102528