Update #5
Closed
Update #5
Conversation
This file contains 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
Rustup r? ghost changelog: none
This adds a minor missing feature to `fake_variadic`, so that it can render `impl From<(T,)> for [T; 1]` correctly.
Signed-off-by: rongfu.leng <lenronfu@gmail.com>
Detect `*` operator on `!Sized` expression The suggestion is new: ``` error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-str-in-return-expr-arg-and-local.rs:15:9 | LL | let x = *""; | ^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = note: all local variables must have a statically known size = help: unsized locals are gated as an unstable feature help: references to `!Sized` types like `&str` are `Sized`; consider not dereferencing the expression | LL - let x = *""; LL + let x = ""; | ``` Fix #128199.
…style-sugg, r=cjgillot Don't suggest turning crate-level attributes into outer style Fixes #127930
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint Revives #120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise. Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`. The suggestion is not made for `&mut CString` or `*mut CString`. r? ``````@cjgillot`````` (since you were the reviewer of the original PR #120176, but feel free to reroll)
Print the generic parameter along with the variance in dumps. This allows to make sure we are testing what we think we are testing. While the tests are correct, I discovered that opaque duplicated args are in the reverse declaration order.
…otriddle rustdoc: show exact case-sensitive matches first fixes #119480
…dtolnay Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods Tracking issue: #86918 Based on the suggestion in #86918 (comment) > Some advantages: > > * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33) > > * Lifetime elision reduces noise in the signature > > * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut` The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs. <details><summary><b>Docs screenshots</b></summary> Current nightly:  `Pin::as_deref_mut` moved into the same block as `as_mut`:  `Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block:  </details> I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method. r? dtolnay
Update `compiler_builtins` to `0.1.121` To pick up rust-lang/compiler-builtins#673 and unblock #129403 r? tgross35
Add myself to the review rotation for libs I am feeling better, and my new job gives me some time to do this.
Make wasm32 platform support docs easier to read
update the doc comment on lintchecker b/c it parses html now
Rollup of 10 pull requests Successful merges: - #128467 (Detect `*` operator on `!Sized` expression) - #128524 (Don't suggest turning crate-level attributes into outer style) - #128735 (Add a special case for `CStr`/`CString` in the `improper_ctypes` lint) - #129429 (Print the generic parameter along with the variance in dumps.) - #129430 (rustdoc: show exact case-sensitive matches first) - #129449 (Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods) - #129481 (Update `compiler_builtins` to `0.1.121`) - #129482 (Add myself to the review rotation for libs) - #129492 (Make wasm32 platform support docs easier to read) - #129512 (update the doc comment on lintchecker b/c it parses html now) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 9 pull requests Successful merges: - #128596 (stabilize const_fn_floating_point_arithmetic) - #129199 (make writes_through_immutable_pointer a hard error) - #129246 (Retroactively feature gate `ConstArgKind::Path`) - #129290 (Pin `cc` to 1.0.105) - #129323 (Implement `ptr::fn_addr_eq`) - #129500 (remove invalid `TyCompat` relation for effects) - #129501 (panicking: improve hint for Miri's RUST_BACKTRACE behavior) - #129505 (interpret: ImmTy: tighten sanity checks in offset logic) - #129510 (Fix `elided_named_lifetimes` in code) r? `@ghost` `@rustbot` modify labels: rollup
…e-const-can-only-call-stable-const
Clippy subtree update r? `@Manishearth`
I am surprised the diff is so small for this enormous crate.
debug-fmt-detail option
I'd like to propose a new option that makes `#[derive(Debug)]` generate no-op implementations that don't print anything, and makes `{:?}` in format strings a no-op.
There are a couple of motivations for this:
1. A more thorough stripping of debug symbols. Binaries stripped of debug symbols still retain some of them through `Debug` implementations. It's hard to avoid that without compiler's help, because debug formatting can be used in many places, including dependencies, and their loggers, asserts, panics, etc.
* In my testing it gives about 2% binary size reduction on top of all other binary-minimizing best practices (including `panic_immediate_abort`). There are targets like Web WASM or embedded where users pay attention to binary sizes.
* Users distributing closed-source binaries may not want to "leak" any symbol names as a matter of principle.
2. Adds ability to test whether code depends on specifics of the `Debug` format implementation in unwise ways (e.g. trying to get data unavailable via public interface, or using it as a serialization format). Because current Rust's debug implementation doesn't change, there's a risk of it becoming a fragile de-facto API that [won't be possible to change in the future](https://www.hyrumslaw.com/). An option that "breaks" it can act as a [grease](https://www.rfc-editor.org/rfc/rfc8701.html).
This implementation is a `-Z fmt-debug=opt` flag that takes:
* `full` — the default, current state.
* `none` — makes derived `Debug` and `{:?}` no-ops. Explicit `impl Debug for T` implementations are left unharmed, but `{:?}` format won't use them, so they may get dead-code eliminated if they aren't invoked directly.
* `shallow` — makes derived `Debug` print only the type's name, without recursing into fields. Fieldless enums print their variant names. `{:?}` works.
The `shallow` option is a compromise between minimizing the `Debug` code, and compatibility. There are popular proc-macro crates that use `Debug::fmt` as a way to convert enum values into their Rust source code.
There's a corresponding `cfg` flag: `#[cfg(fmt_debug = "none")]` that can be used in user code to react to this setting to minimize custom `Debug` implementations or remove unnecessary formatting helper functions.
Improved `checked_isqrt` and `isqrt` methods ### Improved tests of `isqrt` and `checked_isqrt` implementations * Inputs chosen more thoroughly and systematically. * Checks that `isqrt` and `checked_isqrt` have equivalent results for signed types, either equivalent numerically or equivalent as a panic and a `None`. * Checks that `isqrt` has numerically-equivalent results for unsigned types and their `NonZero` counterparts. ### Added benchmarks for `isqrt` implementations ### Greatly sped up `checked_isqrt` and `isqrt` methods * Uses a lookup table for 8-bit integers and then the Karatsuba square root algorithm for larger integers. * Includes optimization hints that give the compiler the exact numeric range of results. ### Feature tracking issue `isqrt` is an unstable feature tracked at #116226. <details><summary>Benchmarked improvements</summary> ### Command used to benchmark ./x bench library/core -- int_sqrt ### Before benchmarks: num::int_sqrt::i128::isqrt 439591.65/iter +/- 6652.70 num::int_sqrt::i16::isqrt 5302.97/iter +/- 160.93 num::int_sqrt::i32::isqrt 62999.11/iter +/- 2022.05 num::int_sqrt::i64::isqrt 125248.81/iter +/- 1674.43 num::int_sqrt::i8::isqrt 123.56/iter +/- 1.87 num::int_sqrt::isize::isqrt 125356.56/iter +/- 1017.03 num::int_sqrt::non_zero_u128::isqrt 437443.75/iter +/- 3535.43 num::int_sqrt::non_zero_u16::isqrt 8604.58/iter +/- 94.76 num::int_sqrt::non_zero_u32::isqrt 62933.33/iter +/- 517.30 num::int_sqrt::non_zero_u64::isqrt 125076.38/iter +/- 11340.61 num::int_sqrt::non_zero_u8::isqrt 221.51/iter +/- 1.58 num::int_sqrt::non_zero_usize::isqrt 136005.21/iter +/- 2020.35 num::int_sqrt::u128::isqrt 439014.55/iter +/- 3920.45 num::int_sqrt::u16::isqrt 8575.08/iter +/- 148.06 num::int_sqrt::u32::isqrt 63008.89/iter +/- 803.67 num::int_sqrt::u64::isqrt 125088.09/iter +/- 879.29 num::int_sqrt::u8::isqrt 230.18/iter +/- 2.04 num::int_sqrt::usize::isqrt 125237.51/iter +/- 4747.83 ### After benchmarks: num::int_sqrt::i128::isqrt 105184.89/iter +/- 1171.38 num::int_sqrt::i16::isqrt 1910.26/iter +/- 78.50 num::int_sqrt::i32::isqrt 34260.34/iter +/- 960.84 num::int_sqrt::i64::isqrt 45939.19/iter +/- 2525.65 num::int_sqrt::i8::isqrt 22.87/iter +/- 0.45 num::int_sqrt::isize::isqrt 45884.17/iter +/- 595.49 num::int_sqrt::non_zero_u128::isqrt 106344.27/iter +/- 780.99 num::int_sqrt::non_zero_u16::isqrt 2790.19/iter +/- 53.43 num::int_sqrt::non_zero_u32::isqrt 33613.99/iter +/- 362.96 num::int_sqrt::non_zero_u64::isqrt 46235.42/iter +/- 429.69 num::int_sqrt::non_zero_u8::isqrt 31.78/iter +/- 0.75 num::int_sqrt::non_zero_usize::isqrt 46208.75/iter +/- 375.27 num::int_sqrt::u128::isqrt 106385.94/iter +/- 1649.95 num::int_sqrt::u16::isqrt 2747.69/iter +/- 28.72 num::int_sqrt::u32::isqrt 33627.09/iter +/- 475.68 num::int_sqrt::u64::isqrt 46182.29/iter +/- 311.16 num::int_sqrt::u8::isqrt 33.10/iter +/- 0.30 num::int_sqrt::usize::isqrt 46165.00/iter +/- 388.41 </details> Tracking Issue for {u8,i8,...}::isqrt #116226 try-job: test-various
Add `-Zlint-llvm-ir` This flag is similar to `-Zverify-llvm-ir` and allows us to lint the generated IR. r? compiler
…rcote riscv64imac: allow shadow call stack sanitizer cc `@Darksonn` for shadow call stack sanitizer support on RV64IMAC and RV64GC
Add `needs-unwind` compiletest directive to `libtest-thread-limit` and replace some `Path` with `path` in `run-make` Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). This PR does two things: 1. Add this to `libtest-thread-limit` ([Why?](#128507 (comment))) ``` //@ needs-unwind // Reason: this should be ignored in cg_clif (Cranelift) CI and anywhere // else that uses panic=abort. ``` 2. Use `path` instead of `Path` to simplify multiple run-make tests.
Add `unreachable_pub`, round 3 A follow-up to #129648. r? `@Urgau`
Fix rustdoc clippy lints Ran clippy on rustdoc and fixed the errors. r? `@notriddle`
Use a reduced recursion limit in the MIR inliner's cycle breaker This probably papers over #128887, but primarily I'm opening this PR because multiple compiler people have thought about making this change which probably means it's a good idea. r? compiler-errors
Rollup of 7 pull requests Successful merges: - #123940 (debug-fmt-detail option) - #128166 (Improved `checked_isqrt` and `isqrt` methods) - #128970 (Add `-Zlint-llvm-ir`) - #129316 (riscv64imac: allow shadow call stack sanitizer) - #129690 (Add `needs-unwind` compiletest directive to `libtest-thread-limit` and replace some `Path` with `path` in `run-make`) - #129732 (Add `unreachable_pub`, round 3) - #129743 (Fix rustdoc clippy lints) r? `@ghost` `@rustbot` modify labels: rollup
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.
No description provided.