Rollup of 8 pull requests #91019
Merged
Rollup of 8 pull requests #91019
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.
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
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=8 |
|
📌 Commit 08c1639 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Nov 18, 2021
Tested on commit rust-lang/rust@cc946fc. Direct link to PR: <rust-lang/rust#91019> 💔 miri on windows: test-pass → test-fail (cc @RalfJung @eddyb @oli-obk). 💔 miri on linux: test-pass → test-fail (cc @RalfJung @eddyb @oli-obk).
|
Finished benchmarking commit (cc946fc): comparison url. Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
|
The regressions happened in the doc benchmarks so #90750 should be the culprit. |
rustbot
added
the
perf-regression-triaged
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.
Successful merges:
-Zassert-incr-stateto assert state of incremental cache #90386 (Add-Zassert-incr-stateto assert state of incremental cache)Vec::removeinVec::swap_remove's docs #90480 (MentionVec::removeinVec::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