Only expect a GAT const param for `type_of` of GAT const arg
IDK why we were account for both `is_ty_or_const` instead of just for a const param, since we're computing the `type_of` a const param specifically.
Fixes#109300
Fix generics_of for impl's RPITIT synthesized associated type
The only useful commit is the last one.
This makes `generics_of` for the impl side RPITIT copy from the trait's associated type and avoid the fn on the impl side which was previously wrongly used.
This solution is better but we still need to fix resolution of the generated generics.
r? ``@compiler-errors``
fix ClashingExternDeclarations lint ICE
Fixes#109334
First "real" contribution, please let me know if I did something wrong.
As I understand it, it's OK if a `#[repr(transparent)]` type has no non-zero sized types (aka is a ZST itself) and the function should just return the type normally instead of panicking
r? `@Nilstrieb`
rustdoc: Remove footnote references from doc summary
Since it's one line, we don't have the footnote definition so it doesn't make sense to have the reference.
Part of https://github.com/rust-lang/rust/issues/109024.
r? `@notriddle`
rustdoc: implement bag semantics for function parameter search
This tweak to the function signature search engine makes things so that, if a type is repeated in the search query, it'll only match if the function actually includes it that many times.
fix: fix ICE in `custom-test-frameworks` feature
Fixes#107454
Simple fix to emit error instead of ICEing. At some point, all the code in `tests.rs` should be refactored, there is a bit of duplication (this PR's code is repeated five times over lol).
r? `@Nilstrieb` (active on the linked issue?)
rustdoc: Fix missing private inlining
Fixes https://github.com/rust-lang/rust/issues/109258.
If the item isn't inlined, it shouldn't have been added into `view_item_stack`. The problem here was that it was not removed, preventing sub items to be inlined if they have a re-export in "upper levels".
cc `@epage`
r? `@notriddle`
This tweak to the function signature search engine makes things so that,
if a type is repeated in the search query, it'll only match if the
function actually includes it that many times.
The name of NativeLib will be presented
Fixes#109144
I was working on a quick fix, but found change the name from `Option<Symbol>` to `Symbol` make life a little bit easier.
fix: don't suggest similar method when unstable
Fixes#109177
Don't display typo suggestions for unstable things, unless the feature flag is enabled.
AFAIK, there are two places this occurs:
- `rustc_resolve`: before type checking, effectively just `FnCtxt::Free`.
- `rustc_hir_typck`: during type checking, for `FnCtxt::Assoc(..)`s.
The linked issue is about the latter, obviously the issue is applicable to both.
r? `@estebank`
Add `useless_anonymous_reexport` lint
This is a follow-up of https://github.com/rust-lang/rust/pull/108936. We once again show all anonymous re-exports in rustdoc, however we also wanted to add a lint to let users know that it very likely doesn't have the effect they think it has.
Add note for mismatched types because of circular dependencies
If you have crate A with a dependency on crate B, and crate B with a dev-dependency on A, then you might see "mismatched types" errors on types that seem to be equal. This PR adds a note that explains that the types are different, because crate B is compiled twice, one time with `cfg(test)` and one time without.
I haven't found a good way to create circular dependencies in UI tests, so I abused the incremental tests instead. As a bonus, incremental tests support "cpass" now.
related to https://github.com/rust-lang/rust/issues/22750
Upgrade to LLVM 16
This updates Rust to LLVM 16. It also updates our host compiler for dist-x86_64-linux to LLVM 16. The reason for that is that Bolt from LLVM 15 is not capable of compiling LLVM 16 (https://github.com/llvm/llvm-project/issues/61114).
LLVM 16.0.0 has been [released](https://discourse.llvm.org/t/llvm-16-0-0-release/69326) on March 18, while Rust 1.70 will become stable on June 1.
Tested images: `dist-x86_64-linux`, `dist-riscv64-linux` (alt), `dist-x86_64-illumos`, `dist-various-1`, `dist-various-2`, `dist-powerpc-linux`, `wasm32`, `armhf-gnu`
Tested images until the usual IPv6 failures: `test-various`
Fix generics mismatch errors for RPITITs on -Zlower-impl-trait-in-trait-to-assoc-ty
This PR stops reporting errors due to different count of generics on the new synthesized associated types for RPITITs. Those were already reported when we compare the function on the triat with the function on the impl.
r? ``@compiler-errors``
Pass the right HIR back from `get_fn_decl`
Fixes#109232
Makes sure that the `fn_id: HirId` that we pass to `suggest_missing_return_type` matches up with the `fn_decl: hir::FnDecl` that we pass to it, so the late-bound vars that we fetch from the former match up with the types in the latter...
This HIR suggestion code really needs a big refactor. I've tried to do it in the past (a couple of attempts), but it's a super tangled mess. It really shouldn't be passing around things like `hir::Node` and just deal with `LocalDefId`s everywhere... Anyways, I'd rather fix this ICE, now.
Do not ICE for unexpected lifetime with ConstGeneric rib
Fixes#109143
r? ````@petrochenkov````
Combining this test with the previous test will affect the previous diagnostics, so I added a separate test case.
Use index based drop loop for slices and arrays
Instead of building two kinds of drop pair loops, of which only one will be eventually used at runtime in a given monomorphization, always use index based loop.
Install projection from RPITIT to default trait method opaque correctly
1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass!
2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why.
3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt.
r? ````@spastorino,```` based off of #109140
inherit_overflow: adapt pattern to also work with v0 mangling
This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases.
Related to #106002 from December.
Wrap the whole LocalInfo in ClearCrossCrate.
MIR contains a lot of information about locals. The primary purpose of this information is the quality of borrowck diagnostics.
This PR aims to drop this information after MIR analyses are finished, ie. starting from post-cleanup runtime MIR.
In cases where it is legal, we should prefer poison values over
undef values.
This replaces undef with poison for aggregate construction and
for uninhabited types. There are more places where we can likely
use poison, but I wanted to stay conservative to start with.
In particular the aggregate case is important for newer LLVM
versions, which are not able to handle an undef base value during
early optimization due to poison-propagation concerns.
Flatten/inline format_args!() and (string and int) literal arguments into format_args!()
Implements https://github.com/rust-lang/rust/issues/78356
Gated behind `-Zflatten-format-args=yes`.
Part of #99012
This change inlines string literals, integer literals and nested format_args!() into format_args!() during ast lowering, making all of the following pairs result in equivalent hir:
```rust
println!("Hello, {}!", "World");
println!("Hello, World!");
```
```rust
println!("[info] {}", format_args!("error"));
println!("[info] error");
```
```rust
println!("[{}] {}", status, format_args!("error: {}", msg));
println!("[{}] error: {}", status, msg);
```
```rust
println!("{} + {} = {}", 1, 2, 1 + 2);
println!("1 + 2 = {}", 1 + 2);
```
And so on.
This is useful for macros. E.g. a `log::info!()` macro could just pass the tokens from the user directly into a `format_args!()` that gets efficiently flattened/inlined into a `format_args!("info: {}")`.
It also means that `dbg!(x)` will have its file, line, and expression name inlined:
```rust
eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!(x), x); // before
eprintln!("[example.rs:1] x = {:#?}", x); // after
```
Which can be nice in some cases, but also means a lot more unique static strings than before if dbg!() is used a lot.
error-msg: impl better suggestion for `E0532`
Fixes#106862
No test as there is already a test which is nearly identical to the example in the linked issue.
Revert #107376 to fix potential `bincode` breakage and `rustc-perf` benchmark.
#107376 caused `rustc-perf`'s `webrender` benchmark to break, by regressing on the `bincode-1.3.3` crate.
~~This PR is a draft revert in case we can't land a fix soon enough, and we'd like to land the revert instead~~
(Though I myself think it'd be safer to do the revert, and run crater when relanding #107376.)
cc `@aliemjay`
Implement checked Shl/Shr at MIR building.
This does not require any special handling by codegen backends,
as the overflow behaviour is entirely determined by the rhs (shift amount).
This allows MIR ConstProp to remove the overflow check for constant shifts.
~There is an existing different behaviour between cg_llvm and cg_clif (cc `@bjorn3).`
I took cg_llvm's one as reference: overflow if `rhs < 0 || rhs > number_of_bits_in_lhs_ty`.~
EDIT: `cg_llvm` and `cg_clif` implement the overflow check differently. This PR uses `cg_llvm`'s implementation based on a `BitAnd` instead of `cg_clif`'s one based on an unsigned comparison.
Rollup of 7 pull requests
Successful merges:
- #108991 (add `enable-warnings` flag for llvm, and disable it by default.)
- #109109 (Use `unused_generic_params` from crate metadata)
- #109111 (Create dirs for build_triple)
- #109136 (Simplify proc macro signature validity check)
- #109150 (Update cargo)
- #109154 (Fix MappingToUnit to support no span of arg_ty)
- #109157 (Remove mw from review rotation for a while)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Simplify proc macro signature validity check
Use an `ObligationCtxt` instead of `normalize_erasing_regions` + `DeepRejectCtxt`. This should both give us a more accurate error message, and also avoid issues like not-well-formed proc macro signatures. Also, let's fall back on the regular type mismatch error reporting for making these diagnostic notes, instead of hard-coding a bunch of specific diagnostics.
Fixes#109129
Use `unused_generic_params` from crate metadata
Due to the way that `separate_provide_extern` interacted with the implementation of `<ty::InstanceDef<'tcx> as Key>::query_crate_is_local`, we actually never hit the foreign provider for `unused_generic_params`.
Additionally, since the *local* provider of `unused_generic_params` calls `should_polymorphize`, which always returns false if the def-id is foreign, this means that we never actually polymorphize monomorphic instances originating from foreign crates.
We don't actually encode `unused_generic_params` for items where all generics are used, so I had to tweak the foreign provider to fall back to `ty::UnusedGenericParams::new_all_used()` to avoid more ICEs when the above bugs were fixed.
Ensure `ptr::read` gets all the same LLVM `load` metadata that dereferencing does
I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`. Trying to narrow it down, it seems that was because `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist.
The root cause is that `ptr::read` is currently implemented via the *untyped* `copy_nonoverlapping`, and thus the `load` doesn't get any type-aware metadata: no `noundef`, no `!range`. This PR solves that by lowering `ptr::read(p)` to `copy *p` in MIR, for which the backends already do the right thing.
Fortuitiously, this also improves the IR we give to LLVM for things like `mem::replace`, and fixes a couple of long-standing bugs where `ptr::read` on `Copy` types was worse than `*`ing them.
Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Move.20array.3A.3AIntoIter.20to.20ManuallyDrop/near/341189936>
cc `@erikdesjardins` `@JakobDegen` `@workingjubilee` `@the8472`
Fixes#106369Fixes#73258
Instead of building two kinds of drop pair loops, of which only one will
be eventually used at runtime in a given monomorphization, always use
index based loop.
Rollup of 9 pull requests
Successful merges:
- #108722 (Support for Fuchsia RISC-V target)
- #108880 (Remove tests/ui/impl-trait/in-trait/new-lowering-strategy in favor of using revisions on existing tests)
- #108909 (Fix object safety checks for new RPITITs)
- #108915 (Remove some direct calls to local_def_id_to_hir_id on diagnostics)
- #108923 (Make fns from other crates with RPITIT work for -Zlower-impl-trait-in-trait-to-assoc-ty)
- #109101 (Fall back to old metadata computation when type references errors)
- #109105 (Don't ICE for late-bound consts across `AnonConstBoundary`)
- #109110 (Don't codegen impossible to satisfy impls)
- #109116 (Emit diagnostic when calling methods on the unit type in method chains)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Emit diagnostic when calling methods on the unit type in method chains
Fixes#104204.
What this PR does: If a method is not found somewhere in a call chain, we check if we called earlier a method with signature `(&mut T, ...) -> ()`. If this is the case then we emit a diagnostic message.
For example given input:
```
vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
```
the current output is:
```
error[E0599]: no method named `sort` found for unit type `()` in the current scope
--> hello.rs:3:72
|
3 | vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
| ^^^^ method not found in `()`
```
after this PR it will be:
```
error[E0599]: no method named `sort` found for unit type `()` in the current scope
--> ./hello.rs:3:72
|
3 | vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
| ^^^^ method not found in `()`
|
note: method `sort_by_key` modifies its receiver in-place, it is not meant to be used in method chains.
--> ./hello.rs:3:53
|
3 | vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
| ^^^^^^^^^^^ this call modifies its receiver in-place
```
Fall back to old metadata computation when type references errors
Projection is a bit too aggressive normalizing `<dyn Trait<[type error]> as Pointee>::Metadata` to `[type error]`, rather than to `DynMetadata<..>`. Side-step that by just falling back to the old structural metadata computation.
Fixes#109078
Make fns from other crates with RPITIT work for -Zlower-impl-trait-in-trait-to-assoc-ty
Only the last two commits are meaningful.
r? `@compiler-errors`
Remove tests/ui/impl-trait/in-trait/new-lowering-strategy in favor of using revisions on existing tests
r? `@compiler-errors`
This one again sits on top of existing approved PRs and it still needs to add revisions to tests in `tests/ui/impl-trait/in-trait` as it only does so for async in traits.
If no method is found when checking method call, we check if we called a method with signature (&mut T, ...) -> (). If this is the case then we emit a diagnostic message
Properly allow macro expanded `format_args` invocations to uses captures
Originally, this was kinda half-allowed. There were some primitive checks in place that looked at the span to see whether the input was likely a literal. These "source literal" checks are needed because the spans created during `format_args` parsing only make sense when it is indeed a literal that was written in the source code directly.
This is orthogonal to the restriction that the first argument must be a "direct literal", not being exanpanded from macros. This restriction was imposed by [RFC 2795] on the basis of being too confusing. But this was only concerned with the argument of the invocation being a literal, not whether it was a source literal (maybe in spirit it meant it being a source literal, this is not clear to me).
Since the original check only really cared about source literals (which is good enough to deny the `format_args!(concat!())` example), macros expanding to `format_args` invocations were able to use implicit captures if they spanned the string in a way that lead back to a source string.
The "source literal" checks were not strict enough and caused ICEs in certain cases (see #106191). So I tightened it up in #106195 to really only work if it's a direct source literal.
This caused the `indoc` crate to break. `indoc` transformed the source literal by removing whitespace, which made it not a "source literal" anymore (which is required to fix the ICE). But since `indoc` spanned the literal in ways that made the old check think that it's a literal, it was able to use implicit captures (which is useful and nice for the users of `indoc`).
This commit properly seperates the previously introduced concepts of "source literal" and "direct literal" and therefore allows `indoc` invocations, which don't create "source literals" to use implicit captures again.
Fixes#106191
[RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
Originally, this was kinda half-allowed. There were some primitive
checks in place that looked at the span to see whether the input was
likely a literal. These "source literal" checks are needed because the
spans created during `format_args` parsing only make sense when it is
indeed a literal that was written in the source code directly.
This is orthogonal to the restriction that the first argument must be a
"direct literal", not being exanpanded from macros. This restriction was
imposed by [RFC 2795] on the basis of being too confusing. But this was
only concerned with the argument of the invocation being a literal, not
whether it was a source literal (maybe in spirit it meant it being a
source literal, this is not clear to me).
Since the original check only really cared about source literals (which
is good enough to deny the `format_args!(concat!())` example), macros
expanding to `format_args` invocations were able to use implicit
captures if they spanned the string in a way that lead back to a source
string.
The "source literal" checks were not strict enough and caused ICEs in
certain cases (see # 106191 (the space is intended to avoid spammy
backreferences)). So I tightened it up in # 106195 to really only work
if it's a direct source literal.
This caused the `indoc` crate to break. `indoc` transformed the source
literal by removing whitespace, which made it not a "source literal"
anymore (which is required to fix the ICE). But since `indoc` spanned
the literal in ways that made the old check think that it's a literal,
it was able to use implicit captures (which is useful and nice for the
users of `indoc`).
This commit properly seperates the previously introduced concepts of
"source literal" and "direct literal" and therefore allows `indoc`
invocations, which don't create "source literals" to use implicit
captures again.
[RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
Remove `identity_future` indirection
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]`annotation.
Fixes https://github.com/rust-lang/rust/issues/104826.
Gracefully handle `#[target_feature]` on statics
The was careful around not calling `fn_sig` on not-functions but well, it wasn't careful enough. This commit makes it a little more careful and also adds tests for a bunch more item kinds.
I was sadly not able to fully bless the test locally because I'm on an aarch64 machine but I hope some manual editing made it work 😅Fix#109079
Treat projections with infer as placeholder during fast reject in new solver
r? ``@lcnr``
Kind of a shame that we need to change all of the call sites for `for_each_relevant_impl`, etc. to pass an extra parameter. I guess I could have the "default" fn which calls a configurable fn?
The was careful around not calling `fn_sig` on not-functions but well,
it wasn't careful enough. This commit makes it a little more careful and
also adds tests for a bunch more item kinds.
Move `Option::as_slice` to an always-sound implementation
This approach depends on CSE to not have any branches or selects when the guessed offset is correct -- which it always will be right now -- but to also be *sound* (just less efficient) if the layout algorithms change such that the guess is incorrect.
The codegen test confirms that CSE handles this as expected, leaving the optimal codegen.
cc JakobDegen #108545
Remove `box_syntax`
r? `@Nilstrieb`
This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected.
It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute.
As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new`
Closes#49733
Strengthen state tracking in const-prop
Some/many of the changes are replicated between both the const-prop lint and the const-prop optimization.
Behaviour changes:
- const-prop opt does not give a span to propagated values. This was useless as that span's primary purpose is to diagnose evaluation failure in codegen.
- we remove the `OnlyPropagateInto` mode. It was only used for function arguments, which are better modeled by a write before entry.
- the tracking of assignments and discriminants make clearer that we do nothing in `NoPropagation` mode or on indirect places.
Gate usages of `dyn*` and const closures in macros
We silently accepted `dyn*` and const closures in macros as long as they didn't expand to anything containing these experimental features, unlike other gated features such as `for<'a>` binders on closures, etc. Let's not do that, to make sure nobody begins relying on this.
rustdoc: use restricted Damerau-Levenshtein distance for search
Based on https://github.com/rust-lang/rust/pull/108200, for the same rationale.
> This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a restricted implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.
Before this change, searching [`prinltn!`] listed `print!` first, followed by `println!`. With this change, `println!` matches more closely.
[`prinltn!`]: https://doc.rust-lang.org/nightly/std/?search=prinltn!
