Skip to content
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 13 pull requests #93119

Merged
merged 40 commits into from
Jan 20, 2022
Merged

Rollup of 13 pull requests #93119

merged 40 commits into from
Jan 20, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tmiasko and others added 30 commits November 20, 2021 10:12
For some time CTFE has been using a dedicated MIR which is never
optimized, so the check for promoted became redundant.
The change is limited to the iteration over indices instead of using
`basic_blocks_mut()` directly, in the case the previous implementation
intentionally avoided invalidating the caches stored in MIR body.
Previously for enums using the `Variants::Single` layout, the variant
index was being confused with its discriminant. For example, in the case
of `enum E { A = 1 }`.

Use `discriminant_for_variant` to avoid the issue.
We have stable options for adding linker arguments; we should have a
stable option to help debug linker arguments.
The documentation makes it clear that the *exact* format of the output
is not a stable guarantee.
Before, the trait's associated item would be used. Now, the impl's
associated item is used. The only exception is for impls that use
default values for associated items set by the trait. In that case,
the trait's associated item is still used.

As an example of the old and new behavior, take this code:

    trait MyTrait {
        type AssocTy;
    }

    impl MyTrait for String {
        type AssocTy = u8;
    }

Before, when resolving a link to `String::AssocTy`,
`resolve_associated_trait_item` would return the associated item for
`MyTrait::AssocTy`. Now, it would return the associated item for
`<String as MyTrait>::AssocTy`, as it claims in its docs.
Before this, the item name and the stability, source link, and "collapse
all docs" would compete for room on a single line, resulting in awkward
wrapping behavior on mobile. This gives a separate line for that
out-of-band information. It also removes the "copy path" icon on mobile
to make a little more room.

Also, switch to flex-wrap: wrap, so anytime there's not enough room for
`source`, it gets bumped to the next line.
Add MaybeUninit::(slice_)as_bytes(_mut)

This adds methods to convert between `MaybeUninit<T>` and a slice of `MaybeUninit<u8>`. This is safe since `MaybeUninit<u8>` can correctly handle padding bytes in any `T`.

These methods are added:
```rust
impl<T> MaybeUninit<T> {
	pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
	pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
	pub fn slice_as_bytes(this: &[MaybeUninit<T>]) -> &[MaybeUninit<u8>];
	pub fn slice_as_bytes_mut(this: &mut [MaybeUninit<T>]) -> &mut [MaybeUninit<u8>];
}
```
…wiser

Fix variant index / discriminant confusion in uninhabited enum branching

Fix confusion between variant index and variant discriminant. The pass
incorrectly assumed that for `Variants::Single` variant index is the same as
variant discriminant.

r? `@wesleywiser`
…rgs, r=pnkfelix

Stabilize `-Z print-link-args` as `--print link-args`

We have stable options for adding linker arguments; we should have a
stable option to help debug linker arguments.

Add documentation for the new option. In the documentation, make it clear that
the *exact* format of the output is not a stable guarantee.
improve `_` constants in item signature handling

removing the "type" from the error messages does slightly worsen the error messages for types, but figuring out whether the placeholder is for a type or a constant and correctly dealing with that seemed fairly difficult to me so I took the easy way out ✨ Imo the error message is still clear enough.

r? `@BoxyUwU` cc `@estebank`
…chenkov

intra-doc: Use the impl's assoc item where possible

Before, the trait's associated item would be used. Now, the impl's
associated item is used. The only exception is for impls that use
default values for associated items set by the trait. In that case,
the trait's associated item is still used.

As an example of the old and new behavior, take this code:

    trait MyTrait {
        type AssocTy;
    }

    impl MyTrait for String {
        type AssocTy = u8;
    }

Before, when resolving a link to `String::AssocTy`,
`resolve_associated_trait_item` would return the associated item for
`MyTrait::AssocTy`. Now, it would return the associated item for
`<String as MyTrait>::AssocTy`, as it claims in its docs.

r? `@petrochenkov`
…_t, r=michaelwoerister

Change lint message to be stronger for &T -> &mut T transmute

The old message implied that it's only UB if you use the reference to mutate, which (as far as I know) is not true. As in, the following program has UB, and a &T -> &mut T transmute is effectively an `unreachable_unchecked`.

```rust
fn main() {
    #[allow(mutable_transmutes)]
    unsafe {
        let _ = std::mem::transmute::<&i32, &mut i32>(&0);
    }
}
```

In the future, it might be a good idea to use the edition system to make this a hard error, since I don't think it is *ever* defined behaviour? Unless we rule that `&UnsafeCell<i32> -> &mut i32` is fine. (That, and you always could just use `.get()`, so you're not losing anything)
…eGomez

Rustdoc mobile: put out-of-band info on its own line

Before this, the item name and the stability, source link, and "collapse
all docs" would compete for room on a single line, resulting in awkward
wrapping behavior on mobile. This gives a separate line for that
out-of-band information. It also removes the "copy path" icon on mobile
to make a little more room.

Demo: https://rustdoc.crud.net/jsha/mobile-column-flex/std/string/struct.String.html

r? `@GuillaumeGomez`
…lacrum

Help optimize out backtraces when disabled

The comment in `rust_backtrace_env` says:

>    // If the `backtrace` feature of this crate isn't enabled quickly return
>   // `None` so this can be constant propagated all over the place to turn
>  // optimize away callers.

but this optimization has regressed, because the only caller of this function had an alternative path that unconditionally (and pointlessly) asked for a full backtrace, so the disabled state couldn't propagate.

I've added a getter for the full format that respects the feature flag, so that the caller will now be able to really optimize out the disabled backtrace path. I've also made `rust_backtrace_env` trivially inlineable when backtraces are disabled.
…r=notriddle

Fix star handling in block doc comments

Fixes rust-lang#92872.

Some extra explanation about this PR and why rust-lang#92357 created this regression: when we merge doc comment kinds for example in:

```rust
/// he
/**
* hello
*/
#[doc = "boom"]
```

We don't want to remove the empty lines between them. However, to correctly compute the "horizontal trim", we still need it, so instead, I put back a part of the "vertical trim" directly in the "horizontal trim" computation so it doesn't impact the output buffer but allows us to correctly handle the stars.

r? `@camelid`
…=lnicola

⬆️ rust-analyzer

r? `@ghost`
…tly, r=pietroalbini

Fix CVE-2022-21658

See https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html. Patches reviewed by `@m-ou-se.`

r? `@ghost`
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 20, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=251

@bors
Copy link
Contributor

bors commented Jan 20, 2022

📌 Commit dbc9749 has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 20, 2022
@pietroalbini
Copy link
Member

@bors p=501

@bors
Copy link
Contributor

bors commented Jan 20, 2022

⌛ Testing commit dbc9749 with merge 777bb86...

@pietroalbini
Copy link
Member

@bors treeclosed-

@bors
Copy link
Contributor

bors commented Jan 20, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 777bb86 to master...

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (777bb86): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@matthiaskrgr matthiaskrgr deleted the rollup-ku3cn5j branch February 13, 2022 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.