Don't normalize xform_ret_ty during method candidate assembly
Fixes https://github.com/rust-lang/rust/issues/85671
Normalizing the return type of a method candidate together with the expected receiver type of the method can lead to valid method candidates being rejected during probing. Specifically in the example of the fixed issue we have a `self_ty` of the form `&A<&[Coef]>` whereas the `impl_ty` of the method would be `&A<_>`, if we normalize the projection in the return type we unify the inference variable with `Cont`, which will lead us to reject the candidate in the sup type check in `consider_probe`. Since we don't actually need the normalized return type during candidate assembly, we postpone the normalization until we consider candidates in `consider_probe`.
Prevent error reporting from outputting a recursion error if it finds an ambiguous trait impl during suggestions
Closes#89275
This fixes the compiler reporting a recursion error during another already in progress error by trying to make a conversion method suggestion and encounters ambiguous trait implementations that can convert a the original type into a type that can then be recursively converted into itself via another method in the trait.
Updated OverflowError struct to be an enum so I could differentiate between passes - it's no longer a ZST but I don't think that should be a problem as they only generate when there's an error in compiling code anyway
Turn vtable_allocation() into a query
This PR removes the untracked vtable-const-allocation cache from the `tcx` and turns the `vtable_allocation()` method into a query.
The change is pretty straightforward and should be backportable without too much effort.
Fixes https://github.com/rust-lang/rust/issues/89598.
Correct decoding of foreign expansions during incr. comp.
Fixes https://github.com/rust-lang/rust/issues/74946
The original issue was due to a wrong assertion in `expn_hash_to_expn_id`.
The secondary issue was due to a mismatch between the encoding and decoding paths for expansions that are created after the TyCtxt is created.
Implement `#[link_ordinal(n)]`
Allows the use of `#[link_ordinal(n)]` with `#[link(kind = "raw-dylib")]`, allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL.
Part of #58713.
Rollup of 7 pull requests
Successful merges:
- #89298 (Issue 89193 - Fix ICE when using `usize` and `isize` with SIMD gathers )
- #89461 (Add `deref_into_dyn_supertrait` lint.)
- #89477 (Move items related to computing diffs to a separate file)
- #89559 (RustWrapper: adapt for LLVM API change)
- #89585 (Emit item no type error even if type inference fails)
- #89596 (Make cfg imply doc(cfg))
- #89615 (Add InferCtxt::with_opaque_type_inference to get_body_with_borrowck_facts)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make cfg imply doc(cfg)
This is a reopening of #79341, rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well):
* `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand, so we need this information in later parts of rustdoc.
* I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation.
* I updated the version for the feature.
There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624)
> I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different.
How/why should they differ?
EDIT: this part has been solved, the current code was fine, just needed a little simplification.
cc `@Nemo157`
r? `@jyn514`
Original PR description:
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via `#[doc(cfg(...))]`, so e.g. to hide a `#[cfg]` you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.
Add `deref_into_dyn_supertrait` lint.
Initial implementation of #89460. Resolves#89190.
Maybe also worth a beta backport if necessary.
r? `@nikomatsakis`
Introduce `tcx.get_diagnostic_name`
Introduces a "reverse lookup" for diagnostic items. This is mainly intended for `@rust-lang/clippy` which often does a long series of `is_diagnostic_item` calls for the same `DefId`.
r? `@oli-obk`
Array `.len()` MIR optimization pass
This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383
fix: alloc-optimisation is only for rust llvm
As discussed at the bottom of #83485.
On a separate note I'll take this chance ask, is it worth pulling in that patch (to recognise `__rust_dealloc`) into Debian's system LLVM? The main factors for us to consider would be (1) is the optimisation significant and (2) is there not any significant negative impact to non-rust packages that use LLVM.
librustdoc: Use correct heading levels.
Closes#89309
This fixes the `<h#>` header tags throughout the docs to reflect a semantic hierarchy.
- I ran a script to manually check that we don't have any files with multiple `<h1>` tags.
- Also checked that we never incorrectly nest e.g. a `<h2>` under an `<h3>`.
- I also spot-checked a bunch of pages (`trait.Read`, `enum.Ordering`, `primitive.isize`, `trait.Iterator`).
Note specific regions involved in 'borrowed data escapes' error
Fixes#67007
Currently, a 'borrowed data escapes' error does not mention
the specific lifetime involved (except indirectly through a suggestion
about adding a lifetime bound). We now explain the specific lifetime
relationship that failed to hold, which improves otherwise vague
error messages.
Consider unfulfilled obligations in binop errors
When encountering a binop where the types would have been accepted, if
all the predicates had been fulfilled, include information about the
predicates and suggest appropriate `#[derive]`s if possible.
Fix#84515.
When encountering a binop where the types would have been accepted, if
all the predicates had been fulfilled, include information about the
predicates and suggest appropriate `#[derive]`s if possible.
Point at trait(s) that needs to be `impl`emented.
Document behavior of `MaybeLiveLocals` regarding enums and field-senstivity
This arose from a [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/MaybeLiveLocals.20and.20Discriminants) where a new contributor attempted to implement a dead-store elimination pass using this analysis. They ran into a nasty hack around `SetDiscriminant` the effect of which is to lets handle assignments of literals to enum-typed locals (e.g. `x = Some(4)`) correctly. This took me a while to figure out.
Document this oddity, so the next person will have an easier time, and add a test to enshrine the current behavior.
r? ``@tmiasko``
Make `proc_macro_derive_resolution_fallback` a future-breakage lint
When `cargo report future-incompatibilities` is stabilized
(see #71249), this will cause dependencies that trigger
this lint to be included in the report.
Move generic error message to separate branches
This decomposes an error message in generic constants into more specific branches, for better
readability.
r? ``@lcnr``
Normalize associated type projections when checking return type of main
This fixes#88609.
Previously, the return type of `fn main()` would not have any associated type projections within normalized before checking if it implements the standard library trait `std::process::Termination`. This commit appears to fix it.
This feels vaguely symptomatic of a problem in the underlying trait solving engine, but I am not sure how I would solve that. I am unsure why the example in #88609 with `assert_impl_termination` and `fn foo()` work, but simply `fn main()` doesn't. The way that I solved this is also probably not the best way to do this, so please let me know if there is a better way to do this.
I have added a build-pass regression test for this issue.
Fixes#67007
Currently, a 'borrowed data escapes' error does not mention
the specific lifetime involved (except indirectly through a suggestion
about adding a lifetime bound). We now explain the specific lifetime
relationship that failed to hold, which improves otherwise vague
error messages.
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg
#[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly
treated as a doc(cfg) to render a message in the documentation.
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via #[doc(cfg(...))], so e.g. to
hide a #[cfg] you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
(since `all()` is always true, it is never shown in the docs)
Don't suggest replacing region with 'static in NLL
Fixes#73159
This is similar to #69350 - if the user didn't initially
write out a 'static lifetime, adding 'static in response to
a lifetime error is usually the wrong thing to do.
