-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 9 pull requests #91016
Closed
Closed
Rollup of 9 pull requests #91016
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
This was the only Clean impl I found with `where` bounds. This impl was doubly-confusing: it was implemented on a tuple and it was polymorphic. Combined, this caused a "spooky action at a distance" effect to make the code very confusing.
Basically, this entails moving the arguments cleaning to the call site. I extracted several local variables because: 1. It makes the code easier to read and understand. 2. If I hadn't, the extra `clean()` calls would have caused complicated tuples to be split across several lines. 3. I couldn't just extract local variables for `args` because then the arguments would be cleaned *before* the generics, while rustdoc expects them to be cleaned *after*. Only extracting `args` caused panics like this: thread 'rustc' panicked at 'assertion failed: cx.impl_trait_bounds.is_empty()', src/librustdoc/clean/utils.rs:462:5 Extracting variables makes the control flow -- and the required order of cleaning -- more explicit.
Otherwise, rustdoc panics with messages like this: thread 'rustc' panicked at 'assertion failed: cx.impl_trait_bounds.is_empty()', src/librustdoc/clean/utils.rs:462:5 This ordering requirement is unrelated to the `clean_fn_decl_with_args` refactoring, but the requirement was uncovered as part of that change. I'm not sure if *all* of these places have the requirement, but I added comments to them just in case.
Because it's always `'tcx`. In fact, some of them use a mixture of passed-in `$tcx` and hard-coded `'tcx`, so no other lifetime would even work. This makes the code easier to read.
Also use `Default::default()` in one `TypedArena::default()`, for consistency with `DroplessArena::default()`.
This commit makes the following functions from `core::str` `const fn`: - `from_utf8[_mut]` (`feature(const_str_from_utf8)`) - `from_utf8_unchecked_mut` (`feature(const_str_from_utf8_unchecked_mut)`) - `Utf8Error::{valid_up_to,error_len}` (`feature(const_str_from_utf8)`)
This function parameter attribute was introduced in rust-lang#44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
…_utf8_unchecked_mut` features
…=Aaron1011 Add `-Zassert-incr-state` to assert state of incremental cache Closes rust-lang#85864.
…=camelid Clean up mess for --show-coverage documentation It was somewhat duplicated for some reasons... Anyway, this remove this duplication and clean up a bit. r? ``@camelid``
Mention `Vec::remove` in `Vec::swap_remove`'s docs Thought this was a nice addition.
…=oli-obk Make slice->str conversion and related functions `const` This PR marks the following APIs as `const`: ```rust // core::str pub const fn from_utf8(v: &[u8]) -> Result<&str, Utf8Error>; pub const fn from_utf8_mut(v: &mut [u8]) -> Result<&mut str, Utf8Error>; pub const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str; impl Utf8Error { pub const fn valid_up_to(&self) -> usize; pub const fn error_len(&self) -> Option<usize>; } ``` Everything but `from_utf8_unchecked_mut` uses `const_str_from_utf8` feature gate, `from_utf8_unchecked_mut` uses `const_str_from_utf8_unchecked_mut` feature gate. --- I'm not sure why `from_utf8_unchecked_mut` was left out being non-`const`, considering that `from_utf8_unchecked` is not only `const`, but **`const` stable**. --- r? ``@oli-obk`` (performance-only `const_eval_select` use)
rustdoc: Replace where-bounded Clean impl with simple function This is the first step in removing the Clean impls for tuples. Either way, this significantly simplifies the code since it reduces the amount of "trait magic". (To clarify, I'm referring to impls like `impl Clean for (A, B)`, not Clean impls that work on tuples in the user's program.) cc `@jyn514`
…=oli-obk require full validity when determining the discriminant of a value This resolves (for now) the semantic question that came up in rust-lang#89764: arguably, reading the discriminant of a value is 'using' that value, so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of *arbitrary* type; all the other primitive MIR operations work on specific types (e.g. `bool` or an integer) and basically implicitly require validity as part of just "doing their job". The alternative would be to just require that the discriminant itself is valid, if any -- but then what do we do for types that do not have a discriminant, which kind of validity do we check? [This code](https://github.com/rust-lang/rust/blob/81117ff930fbf3792b4f9504e3c6bccc87b10823/compiler/rustc_codegen_ssa/src/mir/place.rs#L206-L215) means we have to at least reject uninhabited types, but I would rather not special case that. I don't think this can be tested in CTFE (since validity is not enforced there), I will add a compile-fail test to Miri: ```rust #[allow(enum_intrinsics_non_enums)] fn main() { let i = 2u8; std::mem::discriminant(unsafe { &*(&i as *const _ as *const bool) }); // UB } ``` (I tried running the check even on the CTFE machines, but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp, but that simply does not seem worth the effort currently.) r? `@oli-obk`
…loat-ending-in-dot, r=sanxiyn Avoid suggesting literal formatting that turns into member access Fixes rust-lang#90974
Arenas cleanup I was looking closely at the arenas code and here are some small improvement to readability.
rustc: Remove `#[rustc_synthetic]` This function parameter attribute was introduced in rust-lang#44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself. Noticed while reviewing rust-lang#90947.
@bors r+ rollup=never p=9 |
📌 Commit 377a20e has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Nov 18, 2021
⌛ Testing commit 377a20e with merge e058ef407ce385503dfd284b515d1d67719c7c17... |
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Nov 18, 2021
The job Click to see the possible cause of the failure (guessed by this bot)
|
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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.
Successful merges:
-Zassert-incr-state
to assert state of incremental cache #90386 (Add-Zassert-incr-state
to assert state of incremental cache)Vec::remove
inVec::swap_remove
's docs #90480 (MentionVec::remove
inVec::swap_remove
's docs)const
#90607 (Make slice->str conversion and related functionsconst
)#[rustc_synthetic]
#91002 (rustc: Remove#[rustc_synthetic]
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup