Rollup of 9 pull requests #129993
Closed
Rollup of 9 pull requests #129993
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
Because it's the target libdir. `--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
It's not needed.
It doesn't need to be in there, and the move simplifies lifetimes.
It's not necessary, and just complicates things.
By making it own the index maps, instead of holding references to them. This requires moving the free function `find_candidate` into `Candidate::reset_and_find`. It lets the `'alloc` lifetime be removed everywhere that still has it.
…le out of the code block
…{in,out,err}` config helpers
Previously `Command::stdin` was actually just a stdin buffer helper, but
this is different from `std::process::Command::stdin`. This is
needlessly confusing, and blocks support to add `std{in,out,err}` config
that tests may want to use to e.g. redirect to `/dev/ptmx`.
…a captured lifetime
…-ozkan Call the target libdir target libdir Because it's the target libdir. `--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
fix: get llvm type of global val using `LLVMTypeOf` on a global var always return ptr. so create a new function to access the value type of a global
`impl_trait_overcaptures`: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime
**NOTE:** Review only the first commit carefully. The second one is just moving stuff around, so you can turn whitespace off for that one.
This PR relaxes the `impl_trait_overcaptures` lint to not fire in cases like:
```rust
struct Ctxt<'tcx>(&'tcx ());
impl<'tcx> Ctxt<'tcx> {
fn compute(&self) -> impl Sized + '_ { }
}
```
Specifically, the lint will not fire if **all** overcaptured regions (i.e. those which will be captured in edition 2024, which are not captured today) **satisfy**:
* The region is contravariant (or bivariant) in the function signature
* The region outlives some other region which is captured by the opaque
### The idea behind this
Why is this OK? My reasoning is that since the region is contravariant in the function signature, we know that it can be shortened arbitrarily at the call site. And specifically, we know it can be shortened to be equal to one of the regions that it outlives -- that's why we need to prove that it outlives some other region that *is* captured.
We could technically relax this further, but there would be (IMO somewhat easy) cases to make this a false negative in real code. For example, if the region is invariant, then we can hit issues like:
```rust
struct Ctxt<'tcx>(&'tcx mut &'tcx mut ());
impl<'tcx> Ctxt<'tcx> {
fn compute(&self) -> impl Sized + use<'_, 'tcx> { }
// We use `use<'_, 'tcx>` to show what happens in edition 2024
}
fn test<'a, 'b>(x: &'a Ctxt<'b>, y: &'a Ctxt<'a>) {
let results = [x.compute(), y.compute()];
//~^ ERROR lifetime may not live long enough
// Since both opaques now capture `'tcx`, this enforces that `'a == 'b`.
}
```
### Is this actually totally fine?
There's one case where users might still hit issues, and it's if we turbofish lifetimes directly:
```rust
struct Ctxt<'tcx>(&'tcx ());
impl<'tcx> Ctxt<'tcx> {
fn compute(&self) -> impl Sized + use<'_, 'tcx> { }
}
fn test<'a, 'b>(x: &'a Ctxt<'b>, y: &'a Ctxt<'a>) {
let results = [Ctxt::<'b>::compute(x), Ctxt::<'a>::compute(y)];
//~^ ERROR lifetime may not live long enough
// Since both opaques now capture `'tcx`, this enforces that `'a == 'b`.
// Note that we don't shorten `'b` to `'a` since we turbofished it.
}
```
### Well... we should still warn?
I kinda don't care about this case, though I guess we could possibly downgrade the lint to something like `IMPL_TRAIT_OVERCAPTURES_STRICT` instead of suppressing it altogether. Thoughts? If we were to do this, then I'd probably also opt to include the invariant case in `IMPL_TRAIT_OVERCAPTURES_STRICT` and move it out of `IMPL_TRAIT_OVERCAPTURES`.
…d-items, r=t-rustdoc-frontend [rustdoc] Sort impl associated items by kinds and then by appearance Following [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.22Freeze.22.20order.20of.20items.20in.20.28trait.29.20impls.3F), I implemented it. This brings the following change: impl associated items will now be grouped by kind and will now be first sorted by kind and then by the order they are declared in the source code (like currently). The kinds are sorted in the following order: 1. Constants 2. Types 3. Functions The reason behind this order is that associated constants can be used in associated types (like length in arrays) and both associated types and associated constants can be used in associated functions. So if an associated item from the same impl is used, its definition will always be above where it's being used. cc `@camelid` r? `@notriddle`
Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir First, we add a missing match for `DefKind::SyntheticCoroutineBody` in `dump_mir`. Fixes rust-lang#129703. The second commit (directly below) serves as a test. Second, we reorder the `dump_mir` in `coroutine_by_move_body_def_id` to be *after* we adjust the body source, and change the disambiguator so it reads more like any other MIR body. This also serves as a test for the ICE, since we're dumping the MIR of a body with `DefKind::SyntheticCoroutineBody`. Third, we change the parenting of the synthetic MIR body to have the *coroutine-closure* (i.e. async closure) as its parent, so we don't have long strings of `{closure#0}-{closure#0}-{closure#0}`. try-job: test-various
… r=cjgillot Simplify DestProp memory management The DestProp MIR pass has some convoluted memory management. This PR simplifies it. r? ``@davidtwco``
…, r=notriddle Unify scraped examples with other code examples Fixes rust-lang#129763. This first PR both fixes rust-lang#129763 but also unifies buttons display for code examples:  You can test it [here](https://rustdoc.crud.net/imperio/unify-code-examples/doc/scrape_examples/fn.test.html) and [here](https://rustdoc.crud.net/imperio/unify-code-examples/doc/scrape_examples/fn.test_many.html). I'm planning to send a follow-up to make the buttons generated in JS directly (or I can do it in this PR directly if you prefer). cc ``@willcrichton`` r? ``@notriddle``
Elaborate on deriving vs implementing `Copy` I was reading this documentation and this wasn't immediately clear to me. In my mind, it seemed obvious that a type can only claim to be `Copy` if the bits it is storing can be `Copy`, and in the case of a generic struct that can only be the case if `T: Copy`. So the bound added by the derive seemed necessary at all times, and I thought what the documentation was trying to say is that the custom implementation allows you to add _additional bounds_. Of course what it was actually trying to point out is that just because you have a generic parameter `T`, it doesn't necessarily mean you are storing the bits of `T`. And if you aren't, it may be the case that your own bits can be copied regardless of whether the bits of `T` can be safely copied. Thought it may be worth elaborating to make that a bit more clear. Haven't tested/didn't try to figure out how to render this locally. Mainly not sure if the `PhantomData` back link is going to just work or need some extra stuff, but I figured someone else probably could just tell.
run_make_support: rename `Command::stdin` to `stdin_buf` and add `std{in,out,err}` config helpers
Previously `Command::stdin` was actually just a stdin buffer helper, but
this is different from `std::process::Command::stdin`. This is
needlessly confusing, and blocks support to add `std{in,out,err}` config
helpers that tests may want to use to e.g. redirect to `/dev/ptmx`.
rustbot
added
A-run-make
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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:
impl_trait_overcaptures: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime #129028 (impl_trait_overcaptures: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime)Copy#129938 (Elaborate on deriving vs implementingCopy)Command::stdintostdin_bufand addstd{in,out,err}config helpers #129973 (run_make_support: renameCommand::stdintostdin_bufand addstd{in,out,err}config helpers)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup