It's not clear to me (klinvill) that UserTypeProjections are produced
anymore with the removal of type ascriptions as per
https://github.com/rust-lang/rfcs/pull/3307. Furthermore, it's not clear
to me which variants of ProjectionElem could appear in such projections.
For these reasons, I'm reverting projections in UserTypeProjections to
simple strings until I can get more clarity on UserTypeProjections.
This commit includes richer projections for both Places and
UserTypeProjections. However, the tests only touch on Places. There are
also outstanding TODOs regarding how projections should be resolved to
produce Place types, and regarding if UserTypeProjections should just
contain ProjectionElem<(),()> objects as in MIR.
rustdoc-json: Fix test so it actually checks things
After #111427, no item has a `kind` field, so these assertions could never fail. Instead, assert that those two items arn't present.
r? `@GuillaumeGomez`
Emit #[inline] on derive(Debug)
While working on https://github.com/rust-lang/rust/pull/116583 I noticed that the `cross_crate_inlinable` query identifies a lot of derived `Debug` impls as a MIR body that's little more than a call, which suggests they may be a good candidate for `#[inline]`. So here I've implemented that change specifically.
It seems to provide a nice improvement to build times.
generator layout: ignore fake borrows
fixes#117059
We emit fake shallow borrows in case the scrutinee place uses a `Deref` and there is a match guard. This is necessary to prevent the match guard from mutating the scrutinee: fab1054e17/compiler/rustc_mir_build/src/build/matches/mod.rs (L1250-L1265)
These fake borrows end up impacting the generator witness computation in `mir_generator_witnesses`, which causes the issue in #117059. This PR now completely ignores fake borrows during this computation. This is sound as thse are always removed after analysis and the actual computation of the generator layout happens afterwards.
Only the second commit impacts behavior, and could be backported by itself.
r? types
Extend builtin/auto trait args with error when they have >1 argument
Reuse `extend_with_error` to add error args to any auto trait (or built-in trait like `Copy` that is defined incorrectly) that has additional non-`Self` args.
Fixes#117628
patterns: reject raw pointers that are not just integers
Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not.
This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](https://github.com/rust-lang/rust/pull/116930#issuecomment-1784654073) for some more explanation and context.
Also fixes https://github.com/rust-lang/rust/issues/116929.
Cc `@oli-obk` `@lcnr`
Rollup of 5 pull requests
Successful merges:
- #117263 (handle the case when the change-id isn't found)
- #117282 (Recover from incorrectly ordered/duplicated function keywords)
- #117679 (tests/rustdoc-json: Avoid needless use of `no_core` and `lang_items`)
- #117702 (target: move base and target specifications)
- #117713 (Add test for reexported hidden item with `--document-hidden-items`)
r? `@ghost`
`@rustbot` modify labels: rollup
tests/rustdoc-json: Avoid needless use of `no_core` and `lang_items`
See #117487 for motivation.
I've split it into three commits, depending on how much work it was to remove `#![no_core]`. The first is entirely mechanical, the second makes no logical changes but couldn't be done with find+replace, and the third required rewriting assertions no not depend on having `#![no_core]`. All of the interesting changes for review are in the third commit, so I recommend reviewing commit-by-commit.
After this, 3 tests still use `#![no_core]`:
- `./tests/rustdoc-json/primitives/primitive_impls.rs`. Uses impls on primitives, so needs to simulate core
- `./tests/rustdoc-json/primitives/local_primitive.rs`: Uses `rustc_doc_primitive`, so needs to simulate core
- `./tests/rustdoc-json/impls/auto.rs`: Uses auto traits, so needs to simulate core
But after this change, we only rely on the core-rustc boundary in tests that deliberately test those interactions.
r? ``@GuillaumeGomez``
Fixes#117487
Compute polonius loan scopes over the region graph
In issue #117146 a loan flows into an SCC containing a placeholder, and whose representative is an existential region. Since we currently compute loan scopes by looking at SCCs and their representatives only, polonius would compute kill points for this loan here whereas NLLs would not of course.
There are a few ways to fix this:
- don't try to be efficient by doing the computation over SCCs, and simply look for free regions and placeholders in the successors of the issuing region.
- change how the SCC representatives are picked, biasing towards placeholders over existential regions. They *shouldn't* matter much, but some downstream code may subtly depend on the current scheme (though no tests fail if we do such a change). This is for unrelated reasons also the way #116891 changes the representative computation. So that PR would also fix issue #117146.
- try to remove placeholders from the main path, and contain them to a pre-pass + a post-pass kind of polonius leak check. If possible, it would fix this issue by turning an outlives constraints to a placeholder into a constraint to 'static. This should also fix the issue, as the representative would be the free region in the SCC. We want to prototype this change to see if it's possible to try to simplify the borrowck main path from having to deal with placeholders and higher-ranked subtyping 🤞.
I'd like to take advantage of fuzzing and a crater run sooner rather than later, so that we grow more confidence that the 2 models are indeed equivalent empirically. Therefore this PR implements option 1 to fix the issue now.
We can take care of efficiency later after validation, and once we implement option 3 (which could also impact option 2 and that associated PR, maybe the lack of placeholders could remove the need to change the representative computation) to traverse SCCs and their representative again.
(Or we maybe will have some kind of naive position-dependent outlives propagation by then and this code would have been changed)
Fixes#117146.
r? `@matthewjasper`
coverage: Rename the `run-coverage` test mode to `coverage-run`
Follow-up to https://github.com/rust-lang/rust/pull/117484#issuecomment-1788916563.
Renaming this test mode to `coverage-run` makes it more consistent with the `coverage-map` mode and the shared `tests/coverage` test directory.
---
``@rustbot`` label +A-code-coverage
Add -Zcross-crate-inline-threshold=yes
``@thomcc`` says this would be useful for
> seeing if it makes a difference in some code if i do it when building the sysroot, since -Zbuild-std + lto helps more than it seems like it should
And I've changed the possible values as a reference to ``@Manishearth`` saying
> LLVM's inlining heuristic is "yes".
Only use `normalize_param_env` when normalizing predicate in `check_item_bounds`
Only use the `normalize_param_env` when normalizing the item bound predicate in `check_item_bounds`, instead of using it when processing this obligation as well. This causes <BUG> to reoccur, but hopefully with better caching in the future, we can fix this would having such bad effects on perf.
This PR also fixes#117598. It turns out that the GAT predicate that we install is actually wrong -- given code like:
```
impl<'r> HasValueRef<'r> for Any {
type Database = Any;
}
```
We currently generate a predicate that looks like `<Any as HasValueRef<'r>>::Database = Any`, where `'r` is an early-bound variable. Really this GAT assumption should be universally quantified over the impl's args, i.e. `for<'r> <Any as HasValueRef<'r>>::Database = Any`, but then we'd need the binder to also include all the WC of the impl as well, which we don't support yet, lol.
To avoid `!matches!(...)`, which is hard to think about. Instead every
case now uses direct pattern matching and returns true or false.
Also add a couple of cases to the `stringify.rs` test that currently
print badly.
coverage: Unify `tests/coverage-map` and `tests/run-coverage` into `tests/coverage`
Ever since the introduction of the `coverage-map` suite, it's been awkward to have to manage two separate coverage test directories containing dozens of mostly-identical files.
However, those two suites were separate for good reasons. They have very different requirements (since only one of them requires actually running the test program), running only one suite is noticeably faster than running both, and having separate suites allows them to be blessed separately if desired. So while unifying them was an obvious idea, actually doing so was non-trivial.
---
Nevertheless, this PR finds a way to merge the two suites into one directory while retaining almost all of the developer-experience benefits of having two suites. This required non-trivial implementations of `Step`, but the end result works very smoothly.
---
The first 5 commits are a copy of #117340, which has been closed in favour of this PR.
Method suggestion code tweaks
I was rummaging around the method suggestion code after https://github.com/rust-lang/rust/pull/117006#discussion_r1384153722 and saw a few things to simplify.
This is two unrelated commits, both in the same file. Review them separately, if you'd like.
r? estebank
warn when using an unstable feature with -Ctarget-feature
Setting or unsetting the wrong target features can cause ABI incompatibility (https://github.com/rust-lang/rust/issues/116344, https://github.com/rust-lang/rust/issues/116558). We need to carefully audit features for their ABI impact before stabilization. I just learned that we currently accept arbitrary unstable features on stable and if they are in the list of Rust target features, even unstable, then we don't even warn about that!1 That doesn't seem great, so I propose we introduce a warning here.
This has an obvious loophole via `-Ctarget-cpu`. I'm not sure how to best deal with that, but it seems better to fix what we can and think about the other cases later, maybe once we have a better idea for how to resolve the general mess that are ABI-affecting target features.
