Suggest single quotes when char expected, str provided
If a type mismatch occurs where a char is expected and a string literal is provided, suggest changing the double quotes to single quotes.
We already provide this suggestion in the other direction ( ' -> " ).
Especially useful for new rust devs used to a language in which single/double quotes are interchangeable.
Fixes#92479.
Actually set IMAGE_SCN_LNK_REMOVE for .rmeta
The code intended to set the IMAGE_SCN_LNK_REMOVE flag for the
.rmeta section, however the value of this flag was set to zero.
Instead use the actual value provided by the object crate.
This dates back to the original introduction of this code in
PR #84449, so we were never setting this flag. As I'm not on
Windows, I'm not sure whether that means we were embedding .rmeta
into executables, or whether the section ended up getting stripped
for some other reason.
Remove special-cased stable hashing for HIR module
All other 'containers' (e.g. `impl` blocks) hashed their contents
in the normal, order-dependent way. However, `Mod` was hashing
its contents in a (sort-of) order-independent way. However, the
exact order is exposed to consumers through `Mod.item_ids`,
and through query results like `hir_module_items`. Therefore,
stable hashing needs to take the order of items into account,
to avoid fingerprint ICEs.
Unforuntately, I was unable to directly build a reproducer
for the ICE, due to the behavior of `Fingerprint::combine_commutative`.
This operation swaps the upper and lower `u64` when constructing the
result, which makes the function non-associative. Since we start
the hashing of module items by combining `Fingerprint::ZERO` with
the first item, it's difficult to actually build an example where
changing the order of module items leaves the final hash unchanged.
However, this appears to have been hit in practice in #92218
While we're not able to reproduce it, the fact that proc-macros
are involved (which can give an entire module the same span, preventing
any span-related invalidations) makes me confident that the root
cause of that issue is our method of hashing module items.
This PR removes all of the special handling for `Mod`, instead deriving
a `HashStable` implementation. This makes `Mod` consistent with other
'contains' like `Impl`, which hash their contents through the typical
derive of `HashStable`.
This PR removes all of the `#[stable_hasher(project(name))]`
attributes used in HIR structs. While these attributes are not known
to be causing any issues in practice, we need to hash these in
order for the incremental system to work correctly -
a query could be otherwise be incorrectly marked green
when a change occures in one of the `Span`s that it uses.
Rollup of 6 pull requests
Successful merges:
- #90102 (Remove `NullOp::Box`)
- #92011 (Use field span in `rustc_macros` when emitting decode call)
- #92402 (Suggest while let x = y when encountering while x = y)
- #92409 (Couple of libtest cleanups)
- #92418 (Fix spacing in pretty printed PatKind::Struct with no fields)
- #92444 (Consolidate Result's and Option's methods into fewer impl blocks)
Failed merges:
- #92483 (Stabilize `result_cloned` and `result_copied`)
r? `@ghost`
`@rustbot` modify labels: rollup
Use field span in `rustc_macros` when emitting decode call
This will cause backtraces to point to the location of
the field in the struct/enum, rather than the derive macro.
This makes it clear which field was being decoded when the
backtrace was captured (which is especially useful if
there are multiple fields with the same type).
Remove `NullOp::Box`
Follow up of #89030 and MCP rust-lang/compiler-team#460.
~1 month later nothing seems to be broken, apart from a small regression that #89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely.
r? `@jonas-schievink`
`@rustbot` label T-compiler
Add `#[rustc_clean(loaded_from_disk)]` to assert loading of query result
Currently, you can use `#[rustc_clean]` to assert to that a particular
query (technically, a `DepNode`) is green or red. However, a green
`DepNode` does not mean that the query result was actually deserialized
from disk - we might have never re-run a query that needed the result.
Some incremental tests are written as regression tests for ICEs that
occured during query result decoding. Using
`#[rustc_clean(loaded_from_disk="typeck")]`, you can now assert
that the result of a particular query (e.g. `typeck`) was actually
loaded from disk, in addition to being green.
No functional changes intended.
The LLVM commit
ec501f15a8
removed the signed version of `createExpression`. This adapts the Rust
LLVM wrappers accordingly.
Move `PatKind::Lit` checking from ast_validation to ast lowering
Fixes#92074
This allows us to insert an `ExprKind::Err` when an invalid expression
is used in a literal pattern, preventing later stages of compilation
from seeing an unexpected literal pattern.
Rustdoc: use ThinVec for GenericArgs bindings
The bindings are almost always empty. This reduces the size of `PathSegment` and `GenericArgs` by about one fourth.
Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0
This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options.
This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale, from #89917:
Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore, Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language, not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z, a-z, 0-9, and _.
Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers).
This pull request allows enabling the new v0 symbol-mangling-version.
See #89917 for references to the implementation of v0, and for references to the tool changes to decode Rust symbols.
Support [x; n] expressions in concat_bytes!
Currently trying to use `concat_bytes!` with a repeating array value like `[42; 5]` results in an error:
```
error: expected a byte literal
--> src/main.rs:3:27
|
3 | let x = concat_bytes!([3; 4]);
| ^^^^^^
|
= note: only byte literals (like `b"foo"`, `b's'`, and `[3, 4, 5]`) can be passed to `concat_bytes!()`
```
This makes it so repeating array syntax can be used the same way normal arrays can be. The RFC doesn't explicitly mention repeat expressions, but it seems reasonable to allow them as well, since normal arrays are allowed.
It is possible to make the compiler get stuck compiling forever with `concat_bytes!([3; 999999999])`, but I don't think that's much of an issue since you can do that already with `const X: [u8; 999999999] = [3; 999999999];`.
Contributes to #87555.
Remove effect of `#[no_link]` attribute on name resolution
Previously it hid all non-macro names from other crates.
This has no relation to linking and can change name resolution behavior in some cases (e.g. glob conflicts), in addition to just producing the "unresolved name" errors.
I can kind of understand the possible reasoning behind the current behavior - if you can use names from a `no_link` crates then you can use, for example, functions too, but whether it will actually work or produce link-time errors will depend on random factors like inliner behavior.
(^^^ This is not the actual reason why the current behavior exist, I've looked through git history and it's mostly accidental.)
I think this risk is ok for such an obscure attribute, and we don't need to specifically prevent use of non-macro items from such crates.
(I'm not actually sure why would anyone use `#[no_link]` on a crate, even if it's macro only, if you aware of any use cases, please share. IIRC, at some point it was used for crates implementing custom derives - the now removed legacy ones, not the current proc macros.)
Extracted from https://github.com/rust-lang/rust/pull/91795.
This allows selecting `v0` symbol-mangling without an unstable option.
Selecting `legacy` still requires -Z unstable-options.
Continue supporting -Z symbol-mangling-version for compatibility for
now, but show a deprecation warning for it.
Emit an error for `--cfg=)`
Fixes#73026
See also: #64467, #89468
The issue stems from a `FatalError` being silently raised in
`panictry_buffer`. Normally this is not a problem, because
`panictry_buffer` emits the causes of the error, but they are not
themselves fatal, so they get filtered out by the silent emitter.
To fix this, we use a parser entrypoint which doesn't use
`panictry_buffer`, and we handle the error ourselves.
Fixes#92074
This allows us to insert an `ExprKind::Err` when an invalid expression
is used in a literal pattern, preventing later stages of compilation
from seeing an unexpected literal pattern.
Mark drop calls in landing pads `cold` instead of `noinline`
Now that deferred inlining has been disabled in LLVM (#92110), this shouldn't cause catastrophic size blowup.
I confirmed that the test cases from https://github.com/rust-lang/rust/issues/41696#issuecomment-298696944 still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version)
r? `@nagisa`
cc `@arielb1` (this effectively reverts #42771 "mark calls in the unwind path as !noinline")
cc `@RalfJung` (fixes#46515)
edit: also fixes#87055
[rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape
Fixes#92267.
The problem was that the escape string "%%" does not need to appear at the very beginning of the format string, but
the iterator implementation assumed that it did.
The solution follows the pattern used by `format_foregin:🐚:Subtitution::Escape`: 8ed935e92d/compiler/rustc_builtin_macros/src/format_foreign.rs (L629)
Fix whitespace in pretty printed PatKind::Range
Follow-up to #92238 fixing one of the FIXMEs.
```rust
macro_rules! repro {
($pat:pat) => {
stringify!($pat)
};
}
fn main() {
println!("{}", repro!(0..=1));
}
```
Before: `0 ..=1`
After: `0..=1`
The canonical spacing applied by rustfmt has no space after the lower expr. Rustc's parser diagnostics also do not put a space there:
df96fb166f/compiler/rustc_parse/src/parser/pat.rs (L754)
Fixes#73026
See also: #64467, #89468
The issue stems from a `FatalError` being silently raised in
`panictry_buffer`. Normally this is not a problem, because
`panictry_buffer` emits the causes of the error, but they are not
themselves fatal, so they get filtered out by the silent emitter.
To fix this, we use a parser entrypoint which doesn't use
`panictry_buffer`, and we handle the error ourselves.
Add Attribute::meta_kind
The `AttrItem::meta` function is being called on a lot of places, however almost always the caller is only interested in the `kind` of the result `MetaItem`. Before, the `path` had to be cloned in order to get the kind, now it does not have to be.
There is a larger related "problem". In a lot of places, something wants to know contents of attributes. This is accessed through `Attribute::meta_item_list`, which calls `AttrItem::meta` (now `AttrItem::meta_kind`), among other methods. When this function is called, the meta item list has to be recreated from scratch. Everytime something asks a simple question (like is this item/list of attributes `#[doc(hidden)]`?), the tokens of the attribute(s) are cloned, parsed and the results are allocated on the heap. That seems really unnecessary. What would be the best way to cache this? Turn `meta_item_list` into a query perhaps? Related PR: https://github.com/rust-lang/rust/pull/92227
r? rust-lang/rustdoc
Rollup of 7 pull requests
Successful merges:
- #90383 (Extend check for UnsafeCell in consts to cover unions)
- #91375 (config.rs: Add support for a per-target default_linker option.)
- #91480 (rustdoc: use smaller number of colors to distinguish items)
- #92338 (Add try_reserve and try_reserve_exact for OsString)
- #92405 (Add a couple needs-asm-support headers to tests)
- #92435 (Sync rustc_codegen_cranelift)
- #92440 (Fix mobile toggles position)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Sync rustc_codegen_cranelift
The main highlight this sync is enforcing rustfmt and lack of warnings on cg_clif's CI. I will open a separate PR to remove the cg_clif exceptions for them from this repo.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Store liveness in interval sets for region inference
On the 100,000 line test case from https://github.com/rust-lang/rust/issues/90445, this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results, though with regular malloc), and yields a 9.4x speedup, with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact, but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler, as results on #90445 illustrate.
There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which, at some level, are a less perfect fit for representing liveness, which is almost always composed of contiguous ranges, not point locations).
Fixes#90445.
Import `SourceFile`s from crate before decoding foreign `Span`
Fixes#92163Fixes#92014
When writing to the incremental cache, we encode all `Span`s
we encounter, regardless of whether or not their `SourceFile`
comes from the local crate, or from a foreign crate.
When we decode a `Span`, we use the `StableSourceFileId` we encoded
to locate the matching `SourceFile` in the current session. If this
id corresponds to a `SourceFile` from another crate, then we need to
have already imported that `SourceFile` into our current session.
This usually happens automatically during resolution / macro expansion,
when we try to resolve definitions from other crates. In certain cases,
however, we may try to load a `Span` from a transitive dependency
without having ever imported the `SourceFile`s from that crate, leading
to an ICE.
This PR fixes the issue by enconding the `SourceFile`'s `CrateNum`
when we encode a `Span`. During decoding, we call `imported_source_files()`
when we encounter a foreign `CrateNum`, which ensure that all
`SourceFile`s from that crate are imported into the current session.
Region inference contains several bitsets which are filled with large intervals
representing liveness. These can cause excessive memory usage, and are
relatively slow when growing to large sizes compared to the IntervalSet.
This is a compact, fast storage for variable-sized sets, typically consisting of
larger ranges. It is less efficient than a bitset if ranges are both small and
the domain size is small, but will still perform acceptably. With enormous
domain sizes and large ranges, the interval set performs much better, as it can
be much more densely packed in memory than the uncompressed bit set alternative.
ast: Avoid aborts on fatal errors thrown from mutable AST visitor
Set the node to some dummy value and rethrow the error instead.
When using the old aborting `visit_clobber` in `InvocationCollector::visit_crate` the next tests abort due to fatal errors:
```
ui\modules\path-invalid-form.rs
ui\modules\path-macro.rs
ui\modules\path-no-file-name.rs
ui\parser\issues\issue-5806.rs
ui\parser\mod_file_with_path_attr.rs
```
Follow up to https://github.com/rust-lang/rust/pull/91313.
Refactor variance diagnostics to work with more types
Instead of special-casing mutable pointers/references, we
now support general generic types (currently, we handle
`ty::Ref`, `ty::RawPtr`, and `ty::Adt`)
When a `ty::Adt` is involved, we show an additional note
explaining which of the type's generic parameters is
invariant (e.g. the `T` in `Cell<T>`). Currently, we don't
explain *why* a particular generic parameter ends up becoming
invariant. In the general case, this could require printing
a long 'backtrace' of types, so doing this would be
more suitable for a follow-up PR.
We still only handle the case where our variance switches
to `ty::Invariant`.
Allow loading LLVM plugins with both legacy and new pass manager
Opening a draft PR to get feedback and start discussion on this feature. There is already a codegen option `passes` which allow giving a list of LLVM pass names, however we currently can't use a LLVM pass plugin (as described here : https://llvm.org/docs/WritingAnLLVMPass.html), the only available passes are the LLVM built-in ones.
The proposed modification would be to add another codegen option `pass-plugins`, which can be set with a list of paths to shared library files. These libraries are loaded using the LLVM function `PassPlugin::Load`, which calls the expected symbol `lvmGetPassPluginInfo`, and register the pipeline parsing and optimization callbacks.
An example usage with a single plugin and 3 passes would look like this in the `.cargo/config`:
```toml
rustflags = [
"-C", "pass-plugins=/tmp/libLLVMPassPlugin",
"-C", "passes=pass1 pass2 pass3",
]
```
This would give the same functionality as the opt LLVM tool directly integrated in rust build system.
Additionally, we can also not specify the `passes` option, and use a plugin which inserts passes in the optimization pipeline, as one could do using clang.
Instead of special-casing mutable pointers/references, we
now support general generic types (currently, we handle
`ty::Ref`, `ty::RawPtr`, and `ty::Adt`)
When a `ty::Adt` is involved, we show an additional note
explaining which of the type's generic parameters is
invariant (e.g. the `T` in `Cell<T>`). Currently, we don't
explain *why* a particular generic parameter ends up becoming
invariant. In the general case, this could require printing
a long 'backtrace' of types, so doing this would be
more suitable for a follow-up PR.
We still only handle the case where our variance switches
to `ty::Invariant`.
Add codegen option for branch protection and pointer authentication on AArch64
The branch-protection codegen option enables the use of hint-space pointer
authentication code for AArch64 targets.
rustc_metadata: Encode list of all crate's traits into metadata
While working on https://github.com/rust-lang/rust/pull/88679 I noticed that rustdoc is casually doing something quite expensive, something that is used only for error reporting in rustc - collecting all traits from all crates in the dependency tree.
This PR trades some minor extra time spent by metadata encoder in rustc for major gains for rustdoc (and for rustc runs with errors, which execute the `all_traits` query for better diagnostics).
Rollup of 7 pull requests
Successful merges:
- #92075 (rustdoc: Only special case struct fields for intra-doc links, not enum variants)
- #92118 (Parse and suggest moving where clauses after equals for type aliases)
- #92237 (Visit expressions in-order when resolving pattern bindings)
- #92340 (rustdoc: Start cleaning up search index generation)
- #92351 (Add long error explanation for E0227)
- #92371 (Remove pretty printer space inside block with only outer attrs)
- #92372 (Print space after formal generic params in fn type)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Print space after formal generic params in fn type
Follow-up to #92238 fixing one of the FIXMEs.
```rust
macro_rules! repro {
($ty:ty) => {
stringify!($ty)
};
}
fn main() {
println!("{}", repro!(for<'a> fn(&'a u8)));
}
```
Before: `for<'a>fn(&'a u8)`
After: `for<'a> fn(&'a u8)`
The pretty printer's `print_formal_generic_params` already prints formal generic params correctly with a space, we just need to call it when printing BareFn types instead of reimplementing the printing incorrectly without a space.
83b15bfe1c/compiler/rustc_ast_pretty/src/pprust/state.rs (L1394-L1400)
Visit expressions in-order when resolving pattern bindings
[edited:] Visit the pattern's sub-expressions before defining any bindings.
Otherwise, we might get into a case where a Lit/Range expression in a pattern has a qpath pointing to a Ident pattern that is defined after it, causing an ICE when lowering to HIR. I have a more detailed explanation in the issue linked.
Fixes#92100
Parse and suggest moving where clauses after equals for type aliases
~Mostly the same as #90076, but doesn't make any syntax changes.~ Whether or not we want to land the syntax changes, we should parse the invalid where clause position and suggest moving.
r? `@nikomatsakis`
cc `@petrochenkov` you might have thoughts on implementation
Rollup of 7 pull requests
Successful merges:
- #92076 (Ignore other `PredicateKind`s in rustdoc auto trait finder)
- #92219 (Remove VCVARS_BAT)
- #92238 (Add a test suite for stringify macro)
- #92330 (Add myself to .mailmap)
- #92333 (Tighten span when suggesting lifetime on path)
- #92335 (Document units for `std::column`)
- #92344 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Tighten span when suggesting lifetime on path
This is kind of a hack.
Really the issue here is that we want to suggest the segment's span if the path resolves to something defined outside of the macro, and the macro's span if it resolves to something defined within.. I'll look into seeing if we can do something like that.
Fixes#92324
r? `@cjgillot`
Ignore other `PredicateKind`s in rustdoc auto trait finder
Fixes#92073
There's not really anything we can do with them, and they're
causing ICEs. I'm not using a wildcard match, as we should check
that any new `PredicateKind`s are handled properly by rustdoc.
rustc_metadata: Switch crate data iteration from a callback to iterator
The iteration looks more conventional this way, and some allocations are avoided.
Relax priv-in-pub lint on generic bounds and where clauses of trait impls.
The priv-in-pub lint is a legacy mechanism of the compiler, supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls.
## Current Behavior
On public trait impls, it's currently an **error** to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // ERROR
{}
```
...and it's a **warning** to have have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
pub struct Pub {}
trait Priv {}
impl Priv for Pub {}
impl Trait for Type
where
Pub: Priv // WARNING
{}
```
This lint applies to `where` clauses in other contexts, too; e.g. on free functions:
```rust
struct Priv<T>(T);
pub trait Pub {}
impl<T: Pub> Pub for Priv<T> {}
pub fn function<T>()
where
Priv<T>: Pub // WARNING
{}
```
**These constraints could be relaxed without issue.**
## New Behavior
This lint is relaxed for `where` clauses on trait impls, such that it's okay to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // OK
{}
```
...and it's okay to have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
pub struct Pub {}
trait Priv {}
impl Priv for Pub {}
impl Trait for Type
where
Pub: Priv // OK
{}
```
## Rationale
While the priv-in-pub lint is not essential for soundness, it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance, such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context:
```rust
fn callsite<T>()
where
Priv<T>: Pub // ERROR: omitting this bound is a compile error, but including it is too
{
function::<T>()
}
```
...it cannot do so without repeating `function`'s `where` bound, which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful.
However, this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds, you don't need to forward those private bounds, you can forward the public trait:
```rust
mod upstream {
pub trait Trait {
fn method(&self) {}
}
pub struct Type<T>(T);
pub struct Pub<T>(T);
trait Priv {}
impl<T: Priv> Priv for Pub<T> {}
impl<T> Trait for Type<T>
where
Pub<T>: Priv // WARNING
{}
}
mod downstream {
use super::upstream::*;
fn function<T>(value: Type<T>)
where
Type<T>: Trait // <- no private deets!
{
value.method();
}
}
```
**This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts, including trait definitions, inherent impls, and function definitions. It doesn't need to exist in those cases either, but I figured I'd first target a case where it's mostly pointless.
## Other Notes
- See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397).
- This PR effectively reverts #79291.
All other 'containers' (e.g. `impl` blocks) hashed their contents
in the normal, order-dependent way. However, `Mod` was hashing
its contents in a (sort-of) order-independent way. However, the
exact order is exposed to consumers through `Mod.item_ids`,
and through query results like `hir_module_items`. Therefore,
stable hashing needs to take the order of items into account,
to avoid fingerprint ICEs.
Unforuntately, I was unable to directly build a reproducer
for the ICE, due to the behavior of `Fingerprint::combine_commutative`.
This operation swaps the upper and lower `u64` when constructing the
result, which makes the function non-associative. Since we start
the hashing of module items by combining `Fingerprint::ZERO` with
the first item, it's difficult to actually build an example where
changing the order of module items leaves the final hash unchanged.
However, this appears to have been hit in practice in #92218
While we're not able to reproduce it, the fact that proc-macros
are involved (which can give an entire module the same span, preventing
any span-related invalidations) makes me confident that the root
cause of that issue is our method of hashing module items.
This PR removes all of the special handling for `Mod`, instead deriving
a `HashStable` implementation. This makes `Mod` consistent with other
'contains' like `Impl`, which hash their contents through the typical
derive of `HashStable`.
rustc_metadata: Merge `get_ctor_def_id` and `get_ctor_kind`
Also avoid decoding the whole `ty::AssocItem` to get a `has_self` flag.
A small optimization and cleanup extracted from https://github.com/rust-lang/rust/pull/89059.
CTFE eval_fn_call: use FnAbi to determine argument skipping and compatibility
This makes use of the `FnAbi` type in CTFE/Miri, which `@eddyb` has been saying for years is what we should do.^^ `FnAbi` is used to
- determine which arguments to skip (rather than the previous heuristic of skipping ZST arguments with the Rust ABI)
- impose further restrictions on whether caller and callee are consistent in how a given argument is passed
I was hoping it would also simplify the code, but that is not the case -- the previous type compatibility checks are still required (AFAIK), only the ZST skipping is gone and that took barely any code. We also need some hacks because `FnAbi` assumes a certain way of implementing `caller_location` (by passing extra arguments), but Miri can just read the caller location from the call stack so it doesn't need those arguments. (The fact that every backend has to separately implement support for these arguments seems suboptimal -- looks like this might have been better implemented on the MIR level.) To avoid having to implement those unnecessary arguments in Miri, we just compute *whether* the argument is present on the caller/callee side, but don't actually pass that argument around.
I have no idea if this looks the way `@eddyb` thinks it should look... but it makes Miri's test suite pass. ;)
One of rustc's tests fails unfortunately (`ui/const-generics/issues/issue-67739.rs`), some const generic code that is evaluated too early -- I think that should raise `TooGeneric` but instead it ICEs. My assumption is this is some FnAbi code that has not been properly tested on polymorphic code, but it might also be me calling that FnAbi code the wrong way.
r? `@oli-obk` `@eddyb`
Fixes https://github.com/rust-lang/rust/issues/56166
Miri PR at https://github.com/rust-lang/miri/pull/1928
Remove useless `#[global_allocator]` from rustc and rustdoc.
This was added in #83152, which has several errors in its comments.
This commit also fix up the comments, which are quite wrong and
misleading.
r? `@alexcrichton`
Fixes#92163Fixes#92014
When writing to the incremental cache, we encode all `Span`s
we encounter, regardless of whether or not their `SourceFile`
comes from the local crate, or from a foreign crate.
When we decode a `Span`, we use the `StableSourceFileId` we encoded
to locate the matching `SourceFile` in the current session. If this
id corresponds to a `SourceFile` from another crate, then we need to
have already imported that `SourceFile` into our current session.
This usually happens automatically during resolution / macro expansion,
when we try to resolve definitions from other crates. In certain cases,
however, we may try to load a `Span` from a transitive dependency
without having ever imported the `SourceFile`s from that crate, leading
to an ICE.
This PR fixes the issue by calling `imported_source_files()`
when we encounter a `SourceFile` with a foreign `CrateNum`.
This ensures that all `SourceFile`s from that crate are imported
into the current session.
Store a `DefId` instead of an `AdtDef` in `AggregateKind::Adt`
The `AggregateKind` enum ends up in the final mir `Body`. Currently,
any changes to `AdtDef` (regardless of how significant they are)
will legitimately cause the overall result of `optimized_mir` to change,
invalidating any codegen re-use involving that mir.
This will get worse once we start hashing the `Span` inside `FieldDef`
(which is itself contained in `AdtDef`).
To try to reduce these kinds of invalidations, this commit changes
`AggregateKind::Adt` to store just the `DefId`, instead of the full
`AdtDef`. This allows the result of `optimized_mir` to be unchanged
if the `AdtDef` changes in a way that doesn't actually affect any
of the MIR we build.
Update chalk to 0.75.0
- Compute flags in `intern_ty`
- Remove `tracing-serde` from `PERMITTED_DEPENDENCIES`
- Bump `tracing-tree` to 0.2.0
- Bump `tracing-subscriber` to 0.3.3
Fix duplicate derive clone suggestion
closes https://github.com/rust-lang/rust/issues/91492
The addition of:
```rust
derives.sort();
derives.dedup();
```
is what actually solves the problem.
The rest is just cleanup.
I want to improve the diagnostic message to provide the suggestion as a proper diff but ran into some problems, so I'll attempt that again in a follow up PR.
This follows changes from #67967 and converts remaining `span_bug`s into
delayed bugs, since for const items drop elaboration might be executed
on a MIR which failed borrowck.
The `AggregateKind` enum ends up in the final mir `Body`. Currently,
any changes to `AdtDef` (regardless of how significant they are)
will legitimately cause the overall result of `optimized_mir` to change,
invalidating any codegen re-use involving that mir.
This will get worse once we start hashing the `Span` inside `FieldDef`
(which is itself contained in `AdtDef`).
To try to reduce these kinds of invalidations, this commit changes
`AggregateKind::Adt` to store just the `DefId`, instead of the full
`AdtDef`. This allows the result of `optimized_mir` to be unchanged
if the `AdtDef` changes in a way that doesn't actually affect any
of the MIR we build.
Currently, you can use `#[rustc_clean]` to assert to that a particular
query (technically, a `DepNode`) is green or red. However, a green
`DepNode` does not mean that the query result was actually deserialized
from disk - we might have never re-run a query that needed the result.
Some incremental tests are written as regression tests for ICEs that
occured during query result decoding. Using
`#[rustc_clean(loaded_from_disk="typeck")]`, you can now assert
that the result of a particular query (e.g. `typeck`) was actually
loaded from disk, in addition to being green.
Sync rustc_codegen_cranelift
The main highlight this sync is improved support for inline assembly. Thanks `@nbdd0121!` Inline assembly is still disabled by default for builds in the main rust repo though. Cranelift will now also be built from the crates.io releases rather than the git repo. Git repos are incompatible with vendoring.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Implement StableHash for BitSet and BitMatrix via Hash
This fixes an issue where bit sets / bit matrices the same word
content but a different domain size would receive the same hash.
The issue here is that the logic used to determine which CGU to put the
dead function stubs in doesn't handle cases where a module is never
assigned to a CGU.
The partitioning logic also caused issues in #85461 where inline
functions were duplicated into multiple CGUs resulting in duplicate
symbols.
This commit fixes the issue by removing the complex logic used to assign
dead code stubs to CGUs and replaces it with a much simplier model: we
pick one CGU to hold all the dead code stubs. We pick a CGU which has
exported items which increases the likelihood the linker won't throw
away our dead functions and we pick the smallest to minimize the impact
on compilation times for crates with very large CGUs.
Fixes#86177Fixes#85718Fixes#79622
Remove 'speculative evaluation' of predicates
Performing 'speculative evaluation' introduces caching bugs that
cannot be fixed without invasive changes to projection.
Hopefully, we can win back most of the performance lost by
re-adding 'cache completion'
Fixes#90662
This makes `Obligation` two words bigger, but avoids allocating a lot of
the time.
I previously tried this in #73983 and it didn't help much, but local
timings look more promising now.
The code intended to set the IMAGE_SCN_LNK_REMOVE flag for the
.rmeta section, however the value of this flag was set to zero.
Instead use the actual value provided by the object crate.
This dates back to the original introduction of this code in
PR #84449, so we were never setting this flag. As I'm not on
Windows, I'm not sure whether that means we were embedding .rmeta
into executables, or whether the section ended up getting stripped
for some other reason.
Explicitly set no ELF flags for .rustc section
For a data section, the object crate will set the SHF_ALLOC by default, which is exactly what we don't want. Explicitly set sh_flags to zero to avoid this.
I checked with `objdump -h` that this produces the right flags for ELF.
Fixes#92013.
Remove `in_band_lifetimes` from `rustc_infer`
See #91867 for more information.
This crate actually had a typo `'ctx` in one of its functions:
```diff
-pub fn same_type_modulo_infer(a: Ty<'tcx>, b: Ty<'ctx>) -> bool {
+pub fn same_type_modulo_infer<'tcx>(a: Ty<'tcx>, b: Ty<'tcx>) -> bool {
```
Also, I wasn't entirely sure about the lifetimes in `suggest_new_region_bound`:
```diff
pub fn suggest_new_region_bound(
- tcx: TyCtxt<'tcx>,
+ tcx: TyCtxt<'_>,
err: &mut DiagnosticBuilder<'_>,
fn_returns: Vec<&rustc_hir::Ty<'_>>,
```
Should all of those lifetimes really be distinct?
Enable `#[thread_local]` for all windows-msvc targets
As it stands, `#[thread_local]` is enabled haphazardly for msvc. It seems all 64-bit targets have it enabled, but not 32-bit targets unless they're also UWP targets (perhaps because UWP was added more recently?). So this PR simply enables it for 32-bit targets as well. I can't think of a reason not to and I've confirmed by running tests locally which pass.
See also #91659
Remove `in_band_lifetimes` from `rustc_middle`
See #91867
This was mostly straightforward. In several places, I take advantage
of the fact that lifetimes are non-hygenic: a macro declares the
'tcx' lifetime, which is then used in types passed in as macro
arguments.
Remove `SymbolStr`
This was originally proposed in https://github.com/rust-lang/rust/pull/74554#discussion_r466203544. As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences.
Best reviewed one commit at a time.
r? `@oli-obk`
Re-introduce concept of projection cache 'completion'
Instead of clearing out the cache entirely, we store
the intermediate evaluation result into the cache entry.
This accomplishes several things:
* We avoid the performance hit associated with re-evaluating
the sub-obligations
* We avoid causing issues with incremental compilation, since
the final evaluation result is always the same
* We avoid affecting other uses of the same `InferCtxt` which
might care about 'side effects' from processing the sub-obligations
(e,g. region constraints). Only code that is specifically aware
of the new 'complete' code is affected
Instead of clearing out the cache entirely, we store
the intermediate evaluation result into the cache entry.
This accomplishes several things:
* We avoid the performance hit associated with re-evaluating
the sub-obligations
* We avoid causing issues with incremental compilation, since
the final evaluation result is always the same
* We avoid affecting other uses of the same `InferCtxt` which
might care about 'side effects' from processing the sub-obligations
(e,g. region constraints). Only code that is specifically aware
of the new 'complete' code is affected
Add user seed to `-Z randomize-layout`
Allows users of -`Z randomize-layout` to provide `-Z layout-seed=<seed>` in order to further randomizing type layout randomization. Extension of [compiler-team/#457](https://github.com/rust-lang/compiler-team/issues/457), allows users to change struct layouts without changing code and hoping that item path hashes change, aiding in detecting layout errors
Avoid sorting in hash map stable hashing
Suggested by `@the8472` [here](https://github.com/rust-lang/rust/pull/89404#issuecomment-991813333). I hope that I understood it right, I replaced the sort with modular multiplication, which should be commutative.
Can I ask for a perf. run? However, locally it didn't help at all. Creating the `StableHasher` all over again is probably slowing it down quite a lot. And using `FxHasher` is not straightforward, because the keys and values only implement `HashStable` (and probably they shouldn't be just hashed via `Hash` anyway for it to actually be stable).
Maybe the `StableHash` interface could be changed somehow to better suppor these scenarios where the hasher is short-lived. Or the `StableHasher` implementation could have variants with e.g. a shorter buffer for these scenarios.
Rollup of 7 pull requests
Successful merges:
- #91566 (Apply path remapping to DW_AT_GNU_dwo_name when producing split DWARF)
- #91926 (Remove `in_band_lifetimes` from `rustc_metadata`)
- #91931 (Remove `in_band_lifetimes` from `rustc_codegen_llvm`)
- #92024 (rustc_codegen_llvm: Give each codegen unit a unique DWARF name on all platforms, not just Apple ones.)
- #92037 (Use a const ParamEnv when in default_method_body_is_const)
- #92047 (Set `RUST_BACKTRACE=0` when running location-detail tests)
- #92050 (Add a space and 2 grave accents )
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
For a data section, the object crate will set the SHF_ALLOC by
default, which is exactly what we don't want. Explicitly set
sh_flags to zero to avoid this.
Fixes#92073
There's not really anything we can do with them, and they're
causing ICEs. I'm not using a wildcard match, as we should check
that any new `PredicateKind`s are handled properly by rustdoc.
Rollup of 7 pull requests
Successful merges:
- #91858 (pass -Wl,-z,origin to set DF_ORIGIN when using rpath)
- #91923 (Remove `in_band_lifetimes` from `rustc_query_impl`)
- #91925 (Remove `in_band_lifetimes` from `rustc_privacy`)
- #91977 (Clean up search code and unify function returned values)
- #92018 (Fix typo in "new region bound" suggestion)
- #92022 (Eliminate duplicate codes of expected_found_bool)
- #92032 (hir: Do not introduce dummy type names for `extern` blocks in def paths)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use a const ParamEnv when in default_method_body_is_const
r? `@oli-obk`
This PR fixes the param_env function to return `constness: Const` correctly for trait methods marked with `#[default_method_body_is_const]`. The snippet below is erroneously accepted by the compiler and has been fixed by this change. ([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=12dc6681b2eeee5f604203d96259eeb4))
```rust
#![feature(const_fn_trait_bound)]
#![feature(const_trait_impl)]
trait Tr {}
impl Tr for () {}
const fn foo<T>() where T: ~const Tr {}
pub trait Foo {
#[default_method_body_is_const]
fn foo() {
foo::<()>();
}
}
```
rustc_codegen_llvm: Give each codegen unit a unique DWARF name on all platforms, not just Apple ones.
To avoid breaking split DWARF, we need to ensure that each codegen unit has a
unique `DW_AT_name`. This is because there's a remote chance that different
codegen units for the same module will have entirely identical DWARF entries
for the purpose of the DWO ID, which would violate Appendix F ("Split Dwarf
Object Files") of the DWARF 5 specification. LLVM uses the algorithm specified
in section 7.32 "Type Signature Computation" to compute the DWO ID, which does
not include any fields that would distinguish compilation units. So we must
embed the codegen unit name into the `DW_AT_name`.
Closes#88521.
Remove `in_band_lifetimes` from `rustc_codegen_llvm`
See #91867 for more information.
This one took a while. This crate has dozens of functions not associated with any type, and most of them were using in-band lifetimes for `'ll` and `'tcx`.
Apply path remapping to DW_AT_GNU_dwo_name when producing split DWARF
`--remap-path-prefix` doesn't apply to paths to `.o` (in case of packed) or `.dwo` (in case of unpacked) files in `DW_AT_GNU_dwo_name`. GCC also has this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91888
hir: Do not introduce dummy type names for `extern` blocks in def paths
Use a separate nameless `DefPathData` variant instead.
Extracted from https://github.com/rust-lang/rust/pull/91795.
pass -Wl,-z,origin to set DF_ORIGIN when using rpath
DF_ORIGIN flag signifies that the object being loaded may make reference to the $ORIGIN substitution string.
Some implementations are just ignoring [DF_ORIGIN](http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#df_flags) and do [substitution](http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution) for $ORIGIN if present (whatever DF_ORIGIN presence or not) like glibc. But some others mandate the present of DF_ORIGIN for the substitution (like OpenBSD).
Set the flag inconditionally if rpath is wanted.
One possible fallout is if the linker rejects `-z origin` option.
Improve suggestion to change struct field to &mut
r? ``@estebank``
Now displays a proper underline style suggestion instead of including the code change inline with the message.
Move generator check earlier in inlining.
Inlining into generator may create references to other generators. For instance, inlining `Pin::<&mut from_generator::GenFuture<[generator1]>>::new_unchecked` into `generator2`. This cross reference can then create cycles when computing inlining for `generator1`.
In order to avoid this kind of surprises, we forbid all inlining into generators, and rely on LLVM to do the right thing. The existing `remove-zst-query-cycle` already ICEs in inline-mir mode, so we use it as test.
Split from #91743.
Show the unused type for `unused_results` lint
I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.
Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.
Lint bare traits in AstConv.
Removing the lint from lowering allows to:
- make lowering querification easier;
- have the lint implementation in only one place.
r? `@estebank`
Fix suggestion of additional `pub` when using `pub pub fn ...`
Fix#87694.
Marked as draft to start with because I want to explore doing the same fix for `const const fn` and other repeated-but-valid keywords.
`@rustbot` label A-diagnostics D-invalid-suggestion T-compiler
Implement let-else type annotations natively
Tracking issue: #87335Fixes#89688, fixes#89807, edit: fixes #89960 as well
As explained in https://github.com/rust-lang/rust/issues/89688#issuecomment-940405082, the previous desugaring moved the let-else scrutinee into a dummy variable, which meant if you wanted to refer to it again in the else block, it had moved.
This introduces a new hir type, ~~`hir::LetExpr`~~ `hir::Let`, which takes over all the fields of `hir::ExprKind::Let(...)` and adds an optional type annotation. The `hir::Let` is then treated like a `hir::Local` when type checking a function body, specifically:
* `GatherLocalsVisitor` overrides a new `Visitor::visit_let_expr` and does pretty much exactly what it does for `visit_local`, assigning a local type to the `hir::Let` ~~(they could be deduplicated but they are right next to each other, so at least we know they're the same)~~
* It reuses the code in `check_decl_local` to typecheck the `hir::Let`, simply returning 'bool' for the expression type after doing that.
* ~~`FnCtxt::check_expr_let` passes this local type in to `demand_scrutinee_type`, and then imitates check_decl_local's pattern checking~~
* ~~`demand_scrutinee_type` (the blindest change for me, please give this extra scrutiny) uses this local type instead of of creating a new one~~
* ~~Just realised the `check_expr_with_needs` was passing NoExpectation further down, need to pass the type there too. And apparently this Expectation API already exists.~~
Some other misc notes:
* ~~Is the clippy code supposed to be autoformatted? I tried not to give huge diffs but maybe some rustfmt changes simply haven't hit it yet.~~
* in `rustc_ast_lowering/src/block.rs`, I noticed some existing `self.alias_attrs()` calls in `LoweringContext::lower_stmts` seem to be copying attributes from the lowered locals/etc to the statements. Is that right? I'm new at this, I don't know.
Performing 'speculative evaluation' introduces caching bugs that
cannot be fixed without invasive changes to projection.
Hopefully, we can win back most of the performance lost by
re-adding 'cache completion'
Fixes#90662
Previously it hid all non-macro names from other crates.
This has no relation to linking and can change name resolution behavior in some cases (e.g. glob conflicts), in addition to just producing the "unresolved name" errors
DF_ORIGIN flag signifies that the object being loaded may make reference to the $ORIGIN substitution string.
Some implementations are just ignoring DF_ORIGIN and do substitution for $ORIGIN if present (whatever DF_ORIGIN pr
Set the flag inconditionally if rpath is wanted.
platforms, not just Apple ones.
To avoid breaking split DWARF, we need to ensure that each codegen unit has a
unique `DW_AT_name`. This is because there's a remote chance that different
codegen units for the same module will have entirely identical DWARF entries
for the purpose of the DWO ID, which would violate Appendix F ("Split Dwarf
Object Files") of the DWARF 5 specification. LLVM uses the algorithm specified
in section 7.32 "Type Signature Computation" to compute the DWO ID, which does
not include any fields that would distinguish compilation units. So we must
embed the codegen unit name into the `DW_AT_name`.
Closes#88521.
Implement normalize_erasing_regions queries in terms of 'try' version
Attempt to lessen performance regression caused by https://github.com/rust-lang/rust/pull/91255
r? `@jackh726`
This will cause backtraces to point to the location of
the field in the struct/enum, rather than the derive macro.
This makes it clear which field was being decoded when the
backtrace was captured (which is especially useful if
there are multiple fields with the same type).
Sometimes an obligation depends on a later one, so we can't just process them in order like it was done previously.
This is not a problem in our test suite, but there may be ICEs out there and it will definitely be a problem with lazy TAIT.
remove a empty line
import `module_to_string`
use `contains("test")`
show a suggestion in case module starts_with/ends_with "test"
replace `parent` with `containing`
See #91867
This was mostly straightforward. In several places, I take advantage
of the fact that lifetimes are non-hygenic: a macro declares the
'tcx' lifetime, which is then used in types passed in as macro
arguments.
extend `simplify_type`
might cause a slight perf inprovement and imo more accurately represents what types there are.
considering that I was going to use this in #85048 it seems like we might need this in the future anyways 🤷
Make `TyS::is_suggestable` check for non-suggestable types structually
Not sure if I went overboard checking substs in dyn types, etc. Let me know if I should simplify this function.
Fixes#91832
Remove `in_band_lifetimes` from `rustc_codegen_ssa`
See #91867 for more information.
In `compiler/rustc_codegen_ssa/src/coverageinfo/map.rs`, there are several functions with an explicit `'a` lifetime but only a single `&'a self` parameter. These lifetimes should be redundant given lifetime elision, unless the existential `impl Iterator` has weird issues regarding that. Should the redundant lifetimes be removed?
Handle unordered const/ty generics for object lifetime defaults
*feel like I should have a PR description but cant think of what to put here*
r? ```@lcnr```
By changing `as_str()` to take `&self` instead of `self`, we can just
return `&str`. We're still lying about lifetimes, but it's a smaller lie
than before, where `SymbolStr` contained a (fake) `&'static str`!
Stabilize `iter::zip`
Hello all!
As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised, I hereby submit this stabilization PR on the issue.
As the pull request that introduced the feature (#82917) states, the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement, it has been integrated into the codebase without any trouble, and has been
used in many places across the rust compiler and standard library since March without any issues.
For more details, I would refer to `@cuviper's` original PR, or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).
Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking
This reverts commit b376f5621b, which is the main part of #90499, because it turns out that this causes a good amount of breakage in crates relying on the old behavior. In particular `winit`, `coreaudio` and crates that depend on them are affected. Fixes#91372.
Background:
Before #90499 the behavior was the following: If MACOSX_DEPLOYMENT_TARGET is not set, we pass the minimum supported OS version to LLVM but not to the linker. The linker default depends on the Xcode version and the version of the OS it is running on. That caused one known problem in libcurl with the most recent Xcode versions. #90499 passed the minumum supported version (10.7 for Macos x86-64) to the linker instead. This has shown to be problematic because some crates such as winit, coreaudio implicitly expect a newer minimum OS version. The libcurl issue has been fixed independently (see https://github.com/alexcrichton/curl-rust/issues/417), so a revert should not really be problematic.
Eventually we should probably mimic clang's behavior and fall back to the default of the currently configured Macos SDK for both the LLVM min os target version and MACOSX_DEPLOYMENT_TARGET for linking. That would entail looking at the `Version` property of the `SDKSettings.json` in the currently configured SDK.
Use `OutputFilenames` to generate output file for `-Zllvm-time-trace`
The resulting profile will include the crate name and will be stored in
the `--out-dir` directory.
This implementation makes it convenient to use LLVM time trace together
with cargo, in the contrast to the previous implementation which would
overwrite profiles or store them in `.cargo/registry/..`.
Tweak errors coming from `for`-loop, `?` and `.await` desugaring
* Suggest removal of `.await` on non-`Future` expression
* Keep track of obligations introduced by desugaring
* Remove span pointing at method for obligation errors coming from desugaring
* Point at called local sync `fn` and suggest making it `async`
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:9:10
|
LL | boo().await;
| -----^^^^^^ `()` is not a future
| |
| this call returns `()`
|
= help: the trait `Future` is not implemented for `()`
help: do not `.await` the expression
|
LL - boo().await;
LL + boo();
|
help: alternatively, consider making `fn boo` asynchronous
|
LL | async fn boo () {}
| +++++
```
Fix#66731.
Stabilize asm! and global_asm!
Tracking issue: #72016
It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature!
The main changes in this PR are:
- Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228.
- Stabilizing the `asm` and `global_asm` features.
- Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483).
- All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example.
- Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax, since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`.
- Updating `stdarch` and `compiler-builtins`.
- Updating all the tests.
r? `@joshtriplett`
Looser check for overflowing_binary_op
Fix for issue #91636 tight check resulted in ICE, this makes the check a little looser. It seems `eq` allows comparing of `supertype` and `subtype` if `lhs = supertype` and `rhs = subtype` but not vice versa, is this intended behavior ?
Return an error when `eval_rvalue_with_identities` fails
Previously some code paths would fail to evaluate the rvalue, while
incorrectly indicating success with `Ok`. As a result the previous value
of lhs could have been incorrectly const propagated.
Fixes#91725.
r? `@oli-obk`
Recover on invalid operators `<>` and `<=>`
Thanks to #89871 for showing me how to do this.
Next, I think it'd be nice to recover on `<=>` too, like #89871 intended, if this even works.
