The rules for casting `*mut X<dyn A>` -> `*mut Y<dyn B>` are as follows:
- If `B` has a principal
- `A` must have exactly the same principal (including generics)
- Auto traits of `B` must be a subset of autotraits in `A`
Note that `X<_>` and `Y<_>` can be identity, or arbitrary structs with last field being the dyn type.
The lifetime of the trait object itself (`dyn ... + 'a`) is not checked.
This prevents a few soundness issues with `#![feature(arbitrary_self_types)]` and trait upcasting.
Namely, these checks make sure that vtable is always valid for the pointee.
Stop using specialization in rustc_index and rustc_borrowck
For rustc_borrowck the version with specialization isn't much more readable anyway IMO. For rustc_index it probably doesn't affect perf in any noticeable way anyway.
Optimize SipHash by reordering compress instructions
This PR optimizes hashing by changing the order of instructions in the sip.rs `compress` macro so the CPU can parallelize it better. The new order is taken directly from Fig 2.1 in [the SipHash paper](https://eprint.iacr.org/2012/351.pdf) (but with the xors moved which makes it a little faster). I attempted to optimize it some more after this, but I think this might be the optimal instruction order. Note that this shouldn't change the behavior of hashing at all, only statements that don't depend on each other were reordered.
It appears like the current order hasn't changed since its [original implementation from 2012](fada46c421 (diff-b751133c229259d7099bbbc7835324e5504b91ab1aded9464f0c48cd22e5e420R35)) which doesn't look like it was written with data dependencies in mind.
Running `./x bench library/core --stage 0 --test-args hash` before and after this change shows the following results:
Before:
```
benchmarks:
hash::sip::bench_bytes_4 7.20/iter +/- 0.70
hash::sip::bench_bytes_7 9.01/iter +/- 0.35
hash::sip::bench_bytes_8 8.12/iter +/- 0.10
hash::sip::bench_bytes_a_16 10.07/iter +/- 0.44
hash::sip::bench_bytes_b_32 13.46/iter +/- 0.71
hash::sip::bench_bytes_c_128 37.75/iter +/- 0.48
hash::sip::bench_long_str 121.18/iter +/- 3.01
hash::sip::bench_str_of_8_bytes 11.20/iter +/- 0.25
hash::sip::bench_str_over_8_bytes 11.20/iter +/- 0.26
hash::sip::bench_str_under_8_bytes 9.89/iter +/- 0.59
hash::sip::bench_u32 9.57/iter +/- 0.44
hash::sip::bench_u32_keyed 6.97/iter +/- 0.10
hash::sip::bench_u64 8.63/iter +/- 0.07
```
After:
```
benchmarks:
hash::sip::bench_bytes_4 6.64/iter +/- 0.14
hash::sip::bench_bytes_7 8.19/iter +/- 0.07
hash::sip::bench_bytes_8 8.59/iter +/- 0.68
hash::sip::bench_bytes_a_16 9.73/iter +/- 0.49
hash::sip::bench_bytes_b_32 12.70/iter +/- 0.06
hash::sip::bench_bytes_c_128 32.38/iter +/- 0.20
hash::sip::bench_long_str 102.99/iter +/- 0.82
hash::sip::bench_str_of_8_bytes 10.71/iter +/- 0.21
hash::sip::bench_str_over_8_bytes 11.73/iter +/- 0.17
hash::sip::bench_str_under_8_bytes 10.33/iter +/- 0.41
hash::sip::bench_u32 10.41/iter +/- 0.29
hash::sip::bench_u32_keyed 9.50/iter +/- 0.30
hash::sip::bench_u64 8.44/iter +/- 1.09
```
I ran this on my computer so there's some noise, but you can tell at least `bench_long_str` is significantly faster (~18%).
Also, I noticed the same compress function from the library is used in the compiler as well, so I took the liberty of copy-pasting this change to there as well.
Thanks `@semisol` for porting SipHash for another project which led me to notice this issue in Rust, and for helping investigate. <3
rustdoc: update to pulldown-cmark 0.11
r? rustdoc
This pull request updates rustdoc to the latest version of pulldown-cmark. Along with adding new markdown extensions (which this PR doesn't enable), the new pulldown-cmark version also fixes a large number of bugs. Because all text files successfully parse as markdown, these bugfixes change the output, which can break people's existing docs.
A crater run, https://github.com/rust-lang/rust/pull/121659, has already been run for this change.
The first commit upgrades and fixes rustdoc. The second commit adds a lint for the footnote and block quote parser changes, which break the largest numbers of docs in the Crater run. The strikethrough change was mitigated in pulldown-cmark itself.
Unblocks https://github.com/rust-lang/rust-clippy/pull/12876
Fix incorrect suggestion for extra argument with a type error
Fixes#126246
I tried to fix it in the `find_errors` of ArgMatrix, but seems it's hard to avoid breaking some other test cases.
The root cause is we eliminate the first argument even with a type error at here:
6292b2af62/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs (L664)
So the left argument is always treated as extra one.
But if there is already a type error, an error message will be generated firstly, which make this issue a trivial one.
Make jump threading state sparse
Continuation of https://github.com/rust-lang/rust/pull/127024
Both dataflow const-prop and jump threading involve cloning the state vector a lot. This PR replaces the data structure by a sparse vector, considering:
- that jump threading state is typically very sparse (at most 1 or 2 set entries);
- that dataflow const-prop is disabled by default;
- that place/value map is very eager, and prone to creating an overly large state.
The first commit is shared with the previous PR to avoid needless conflicts.
r? `@oli-obk`
Remove global error count checks from typeck
Some of these are not reachable anymore, others can now rely on information local to the current typeck run. One check was actually invalid, because it was relying on wfcheck running before typeck, which is not guaranteed in the query system and usually easy to create ICEing examples for via const eval (which runs typeck before wfcheck)
Add `as_lang_item` to `LanguageItems`, new trait solver
Add `as_lang_item` which turns `DefId` into a `TraitSolverLangItem` in the new trait solver, so we can turn the large chain of if statements in `assemble_builtin_impl_candidates` into a match instead.
r? lcnr
linker: Link dylib crates by path
Linkers seem to support linking dynamic libraries by path.
Not sure why the previous scheme with splitting the path into a directory (passed with `-L`) and a name (passed with `-l`) was used (upd: likely due to https://github.com/rust-lang/rust/pull/126094#issuecomment-2155063414).
When we split a library path `some/dir/libfoo.so` into `-L some/dir` and `-l foo` we add `some/dir` to search directories for *all* libraries looked up by the linker, not just `foo`, and `foo` is also looked up in *all* search directories not just `some/dir`.
Technically we may find some unintended libraries this way.
Therefore linking dylibs via a full path is both simpler and more reliable.
It also makes the set of search directories more easily reproducible when we need to lookup some native library manually (like in https://github.com/rust-lang/rust/pull/123436).
Re-implement a type-size based limit
r? lcnr
This PR reintroduces the type length limit added in #37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in #72412, which caused the `walk` function to no longer walk over identical elements.
Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode).
This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired.
Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future.
Fixes#125460
Actually report normalization-based type errors correctly for alias-relate obligations in new solver
We have some special casing to report type mismatch errors that come from projection predicates, but we don't do that for alias-relate obligations. This PR implements that. There's a bit of code duplication, but 🤷
Best reviewed without whitespace.
r? lcnr
Check alias args for WF even if they have escaping bound vars
#### What
This PR stops skipping arguments of aliases if they have escaping bound vars, instead recursing into them and only discarding the resulting obligations referencing bounds vars.
#### An example:
From the test:
```
trait Trait {
type Gat<U: ?Sized>;
}
fn test<T>(f: for<'a> fn(<&'a T as Trait>::Gat<&'a [str]>)) where for<'a> &'a T: Trait {}
//~^ ERROR the size for values of type `[()]` cannot be known at compilation time
fn main() {}
```
We now prove that `str: Sized` in order for `&'a [str]` to be well-formed. We were previously unconditionally skipping over `&'a [str]` as it referenced a buond variable. We now recurse into it and instead only discard the `[str]: 'a` obligation because of the escaping bound vars.
#### Why?
This is a change that improves consistency about proving well-formedness earlier in the pipeline, which is necessary for future work on where-bounds in binders and correctly handling higher-ranked implied bounds. I don't expect this to fix any unsoundness.
#### What doesn't it fix?
Specifically, this doesn't check projection predicates' components are well-formed, because there are too many regressions: https://github.com/rust-lang/rust/pull/123737#issuecomment-2052198478
Since this codegen flag now only controls LLVM-generated comments rather than
all assembly comments, make the name more accurate (and also match Clang).
Rewrite handling of universe-leaking placeholder regions into outlives constraints
This commit prepares for Polonius by moving handling of leak check/universe errors out of the inference step by rewriting any universe error into an outlives-static constraint.
This variant is a work in progress but seems to pass most tests.
Note that a few debug assertions no longer hold; a few extra eyes on those changes are appreciated!
Fix `FnMut::call_mut`/`Fn::call` shim for async closures that capture references
I adjusted async closures to be able to implement `Fn` and `FnMut` *even if* they capture references, as long as those references did not need to borrow data from the closure captures themselves. See #125259.
However, when I did this, I didn't actually relax an assertion in the `build_construct_coroutine_by_move_shim` shim code, which builds the `Fn`/`FnMut`/`FnOnce` implementations for async closures. Therefore, if we actually tried to *call* `FnMut`/`Fn` on async closures, it would ICE.
This PR adjusts this assertion to ensure that we only capture immutable references in closures if they implement `Fn`/`FnMut`. It also adds a bunch of tests and makes more of the async-closure tests into `build-pass` since we often care about these tests actually generating the right closure shims and stuff. I think it might be excessive to *always* use build-pass here, but 🤷 it's not that big of a deal.
Fixes#127019Fixes#127012
r? oli-obk
Parenthesize break values containing leading label
The AST pretty printer previously produced invalid syntax in the case of `break` expressions with a value that begins with a loop or block label.
```rust
macro_rules! expr {
($e:expr) => {
$e
};
}
fn main() {
loop {
break expr!('a: loop { break 'a 1; } + 1);
};
}
```
`rustc -Zunpretty=expanded main.rs `:
```console
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
macro_rules! expr { ($e:expr) => { $e }; }
fn main() { loop { break 'a: loop { break 'a 1; } + 1; }; }
```
The expanded code is not valid Rust syntax. Printing invalid syntax is bad because it blocks `cargo expand` from being able to format the output as Rust syntax using rustfmt.
```console
error: parentheses are required around this expression to avoid confusion with a labeled break expression
--> <anon>:9:26
|
9 | fn main() { loop { break 'a: loop { break 'a 1; } + 1; }; }
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
help: wrap the expression in parentheses
|
9 | fn main() { loop { break ('a: loop { break 'a 1; }) + 1; }; }
| + +
```
This PR updates the AST pretty-printer to insert parentheses around the value of a `break` expression as required to avoid this edge case.
And update the comment. Clearly the return type of this function was
changed at some point in the past, but its name and comment weren't
updated to match.
The number of source code bytes can't exceed a `u32`'s range, so a token
position also can't. This reduces the size of `Parser` and
`LazyAttrTokenStreamImpl` by eight bytes each.
Currently it uses a mixture of functional style (`flat_map`) and
imperative style (`push`), which is a bit hard to read. This commit
converts it to fully imperative, which is more concise and avoids the
need for `smallvec`.
I.e. change the return type from `TokenStream` to `Vec<TokenTree>`.
Most of the callsites require a `TokenStream`, but the recursive call
used to create `target_tokens` requires a `Vec<TokenTree>`. It's easy
to convert a `Vec<TokenTree>` to a `TokenStream` (just call
`TokenStream::new`) but it's harder to convert a `TokenStream` to a
`Vec<TokenTree>` (either iterate/clone/collect, or use `Lrc::into_inner`
if appropriate).
So this commit changes the return value to simplify that `target_tokens`
call site.
Use full expr span for return suggestion on type error/ambiguity
We sometimes use parts of an expression rather than the whole thing for an obligation span. For example, a method obligation will just point to the path segment corresponding to the `method` in `rcvr.method(args)`.
So let's not use that assuming it'll point to the *whole* expression span, which we can access from the expr hir id we store in `ObligationCauseCode::WhereClauseInExpr`.
Fixes#127109
linker: Refactor interface for passing arguments to linker
Separate arguments into passed to the underlying linker, to cc wrapper, or supported by both.
Also avoid allocations in all the argument passing functions.
The interfaces would look nicer if not the limitations on returning `&mut Self` in `dyn`-compatible traits, and unnecessary conflicts between `Trait` and `dyn Trait` methods.
try-job: armhf-gnu
try-job: aarch64-gnu
try-job: dist-x86_64-linux
try-job: x86_64-msvc
try-job: i686-msvc
try-job: dist-x86_64-apple
try-job: test-various
In 126578 we ended up with more binary size increases than expected.
This change attempts to avoid inlining large things into small things, to avoid that kind of increase, in cases when top-down inlining will still be able to do that inlining later.
Rollup of 7 pull requests
Successful merges:
- #126923 (test: dont optimize to invalid bitcasts)
- #127090 (Reduce merge conflicts from rustfmt's wrapping)
- #127105 (Only update `Eq` operands in GVN if it can update both sides)
- #127150 (Fix x86_64 code being produced for bare-metal LoongArch targets' `compiler_builtins`)
- #127181 (Introduce a `rustc_` attribute to dump all the `DefId` parents of a `DefId`)
- #127182 (Fix error in documentation for IpAddr::to_canonical and Ipv6Addr::to_canonical)
- #127191 (Ensure `out_of_scope_macro_calls` lint is registered)
r? `@ghost`
`@rustbot` modify labels: rollup
This version is a squash-rebased version of a series
of exiermental commits, since large parts of them
were broken out into PR #125069.
It explicitly handles universe violations in higher-kinded
outlives constraints by adding extra outlives static constraints.
Introduce a `rustc_` attribute to dump all the `DefId` parents of a `DefId`
We've run into a bunch of issues with anon consts having the wrong generics and it would have been incredibly helpful to be able to quickly slap a `rustc_` attribute to check what `tcx.parent(` will return on the relevant DefIds.
I wasn't sure of a better way to make this work for anon consts than requiring the attribute to be on the enclosing item and then walking the inside of it to look for any anon consts. This particular method will honestly break at some point when we stop having a `DefId` available for anon consts in hir but that's for another day...
r? ``@compiler-errors``
Reduce merge conflicts from rustfmt's wrapping
Imports in this file are changed by many different features. Rustfmt insists on reformatting and rewrapping the imports every time they change, which causes chronic merge conflicts.
I've split the big import into multiple smaller ones, so that different features will conflict less often.
Automatically taint InferCtxt when errors are emitted
r? `@nnethercote`
Basically `InferCtxt::dcx` now returns a `DiagCtxt` that refers back to the `Cell<Option<ErrorGuaranteed>>` of the `InferCtxt` and thus when invoking `Diag::emit`, and the diagnostic is an error, we taint the `InferCtxt` directly.
That change on its own has no effect at all, because `InferCtxt` already tracks whether errors have been emitted by recording the global error count when it gets opened, and checking at the end whether the count changed. So I removed that error count check, which had a bit of fallout that I immediately fixed by invoking `InferCtxt::dcx` instead of `TyCtxt::dcx` in a bunch of places.
The remaining new errors are because an error was reported in another query, and never bubbled up. I think they are minor enough for this to be ok, and sometimes it actually improves diagnostics, by not silencing useful diagnostics anymore.
fixes#126485 (cc `@olafes)`
There are more improvements we can do (like tainting in hir ty lowering), but I would rather do that in follow up PRs, because it requires some refactorings.
Make `feature(effects)` require `-Znext-solver`
Per https://github.com/rust-lang/rust/pull/120639#pullrequestreview-2144804638
I made this a hard error because otherwise it should be a lint and that seemed more complicated. Not sure if this is the best place to put the error though.
r? project-const-traits
coverage: Avoid getting extra unexpansion info when we don't need it
Several callers of `unexpand_into_body_span_with_visible_macro` would immediately discard the additional macro-related information, which is wasteful. We can avoid this by having them instead call a simpler method that just returns the span they care about.
This PR also moves the relevant functions out of `coverage::spans::from_mir` and into a new submodule `coverage::unexpand`, so that calling them from `coverage::mappings` is less awkward.
There should be no actual changes to coverage-instrumentation output, as demonstrated by the absence of test updates.
Replace some magic booleans in match-lowering with enums
This PR takes some boolean arguments used by the match-lowering code, and replaces them with dedicated enums that more clearly express their effect, while also making it much easier to find how each value is ultimately used.
Remove the `box_pointers` lint.
As the comment says, this lint "is mostly historical, and not particularly useful". It's not worth keeping it around.
r? ``@estebank``
Subtree sync for rustc_codegen_cranelift
The main highlight this time is support for arm64 macOS in cg_clif. A future PR will enable distributing it as rustup component.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Rollup of 6 pull requests
Successful merges:
- #126705 (Updated docs on `#[panic_handler]` in `library/core/src/lib.rs`)
- #126876 (Add `.ignore` file to make `config.toml` searchable in vscode)
- #126906 (Small fixme in core now that split_first has no codegen issues)
- #127023 (CI: rename Rust for Linux CI job)
- #127131 (Remove unused `rustc_trait_selection` dependencies)
- #127134 (Print `TypeId` as a `u128` for `Debug`)
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid cloning jump threading state when possible
The current implementation of jump threading passes most of its time cloning its state. This PR attempts to avoid such clones by special-casing the last predecessor when recursing through a terminator.
This is not optimal, but a first step while I refactor the state data structure to be sparse.
The two other commits are drive-by.
Fixes https://github.com/rust-lang/rust/issues/116721
r? `@oli-obk`
These particular callers don't actually use the returned macro information, so
they can use a simpler span-unexpansion function that doesn't return it.
The previous boolean used `true` to indicate that storage-live should _not_ be
emitted, so all occurrences of `Yes` and `No` should be the logical opposite of
the previous value.
The new enum `DeclareLetBindings` has three variants:
- `Yes`: Declare `let` bindings as normal, for `if` conditions.
- `No`: Don't declare bindings, for match guards and let-else.
- `LetNotPermitted`: Assert that `let` expressions should not occur.
Remove unused `rustc_trait_selection` dependencies
Found using `cargo-machete`. The `bitflags` and `derivative` crates were added for the new trait solver, but weren't removed when the next trait solver code was uplifted to a separate crate.
Rollup of 9 pull requests
Successful merges:
- #123237 (Various rustc_codegen_ssa cleanups)
- #126960 (Improve error message in tidy)
- #127002 (Implement `x perf` as a separate tool)
- #127081 (Add a run-make test that LLD is not being used by default on the x64 beta/stable channel)
- #127106 (Improve unsafe extern blocks diagnostics)
- #127110 (Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.)
- #127114 (fix: prefer `(*p).clone` to `p.clone` if the `p` is a raw pointer)
- #127118 (Show `used attribute`'s kind for user when find it isn't applied to a `static` variable.)
- #127122 (Remove uneccessary condition in `div_ceil`)
r? `@ghost`
`@rustbot` modify labels: rollup
Show `used attribute`'s kind for user when find it isn't applied to a `static` variable.
For example :
```rust
extern "C" {
#[used] //~ ERROR attribute must be applied to a `static` variable
static FOO: i32; // show the kind of this item to help user understand why the error is reported.
}
```
fixes#126789
fix: prefer `(*p).clone` to `p.clone` if the `p` is a raw pointer
Fixes https://github.com/rust-lang/rust/issues/126863
I wonder if there is a better way to solve the regression problem of this test case:
`tests/ui/borrowck/issue-20801.rs`.
It's okay to drop the dereference symbol in this scenario.
But it's not correct in https://github.com/rust-lang/rust/issues/126863
```
help: consider removing the dereference here
|
5 - let inner: String = *p;
5 + let inner: String = p;
```
I haven't found out how to tell if clone pointer is allowed, i.e. no type mismatch occurs
Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.
Recommit after refactoring based on comment:
https://github.com/rust-lang/rust/pull/126017#issuecomment-2189149361
But when changing return type's lifetime to `ReError` will affect the subsequent borrow check process and cause test11 in typeck_type_placeholder_item.rs to lost E0515 message.
```rust
fn test11(x: &usize) -> &_ {
//~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types
&x //~ ERROR cannot return reference to function parameter(this E0515 msg will disappear)
}
```
fixes#125488
r? ``@pnkfelix``
Improve unsafe extern blocks diagnostics
Closes#126327
For this code:
```rust
extern {
pub fn foo();
pub safe fn bar();
}
```
We get ...
```
error: items in unadorned `extern` blocks cannot have safety qualifiers
--> test.rs:3:5
|
3 | pub safe fn bar();
| ^^^^^^^^^^^^^^^^^^
|
help: add unsafe to this `extern` block
|
1 | unsafe extern {
| ++++++
error[E0658]: `unsafe extern {}` blocks and `safe` keyword are experimental
--> test.rs:3:9
|
3 | pub safe fn bar();
| ^^^^
|
= note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information
= help: add `#![feature(unsafe_extern_blocks)]` to the crate attributes to enable
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0658`.
```
And then making the extern block unsafe, we get ...
```
error: extern block cannot be declared unsafe
--> test.rs:1:1
|
1 | unsafe extern {
| ^^^^^^
|
= note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information
= help: add `#![feature(unsafe_extern_blocks)]` to the crate attributes to enable
error: items in unadorned `extern` blocks cannot have safety qualifiers
--> test.rs:3:5
|
3 | pub safe fn bar();
| ^^^^^^^^^^^^^^^^^^
error[E0658]: `unsafe extern {}` blocks and `safe` keyword are experimental
--> test.rs:3:9
|
3 | pub safe fn bar();
| ^^^^
|
= note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information
= help: add `#![feature(unsafe_extern_blocks)]` to the crate attributes to enable
error: aborting due to 3 previous errors
For more information about this error, try `rustc --explain E0658`.
```
r? ``@compiler-errors``
Implement new effects desugaring
cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.
* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide
Fixes#119717Fixes#123664Fixes#124857Fixes#126148
Move binder and polarity parsing into `parse_generic_ty_bound`
Let's pull out the parts of #127054 which just:
1. Make the parsing code less confusing
2. Fix `?use<>` (to correctly be denied)
3. Improve `T: for<'a> 'a` diagnostics
This should have no user-facing effects on stable parsing.
r? fmease
rustc_data_structures: Explicitly check for 64-bit atomics support
Instead of keeping a list of architectures which have native support
for 64-bit atomics, just use #[cfg(target_has_atomic = "64")] and its
inverted counterpart to determine whether we need to use portable
AtomicU64 on the target architecture.
Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated
Rename:
* `super_predicates_of` -> `explicit_super_predicates_of`
* `implied_predicates_of` -> `explicit_implied_predicates_of`
* `supertraits_containing_assoc_item` -> `explicit_supertraits_containing_assoc_item`
This makes it clearer that, unlike (for example) [`TyCtxt::super_traits_of`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.super_traits_of), we don't automatically elaborate this set of predicates.
r? ``@lcnr`` or ``@oli-obk`` or someone from t-types idc
Recommit after refactoring based on comment:
https://github.com/rust-lang/rust/pull/126017#issuecomment-2189149361
But when changing return type's lifetime to `ReError` will affect the subsequent borrow check process and cause test11 in typeck_type_placeholder_item.rs to lost E0515 message.
```rust
fn test11(x: &usize) -> &_ {
//~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types
&x //~ ERROR cannot return reference to function parameter(this E0515 msg will disappear)
}
```
Rollup of 11 pull requests
Successful merges:
- #123714 (Add test for fn pointer duplication.)
- #124091 (Update AST validation module docs)
- #127015 (Switch back `non_local_definitions` lint to allow-by-default)
- #127016 (docs: check if the disambiguator matches its suffix)
- #127029 (Fix Markdown tables in platform-support.md)
- #127032 (Enable const casting for `f16` and `f128`)
- #127055 (Mark Hasher::finish as #[must_use])
- #127068 (Stall computing instance for drop shim until it has no unsubstituted const params)
- #127070 (add () to the marker_impls macro for ConstParamTy)
- #127071 (Remove (deprecated & unstable) {to,from}_bits pointer methods)
- #127078 (Enable full tools and profiler for LoongArch Linux targets)
r? `@ghost`
`@rustbot` modify labels: rollup
Stall computing instance for drop shim until it has no unsubstituted const params
Do not inline the drop shim for types that still have unsubstituted const params.
## Why?
#127030 ICEs because it tries to inline the drop shim for a type with an unsubstituted const param. In order to generate this shim, this requires calling the drop shim builder, which invokes the trait solver to compute whether constituent types need drop (since we compute if a type is copy to disqualify any `Drop` behavior):
9c3bc805dd/compiler/rustc_mir_dataflow/src/elaborate_drops.rs (L378)
However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env:
9c3bc805dd/compiler/rustc_mir_transform/src/shim.rs (L278)
(which is the param-env of `std::ptr::drop_in_place`)
This param-env is notably missing `ConstParamHasTy` predicates, and since we removed the type from consts in https://github.com/rust-lang/rust/pull/125958, we literally cannot prove these predicates in this (relatively) empty param-env. This currently happens in places like the MIR inliner, but may happen elsewhere such as in lints that resolve terminators.
## What?
We force the inliner to not consider calls for `drop_in_place` for types that have unsubstituted const params.
## So what?
This may negatively affect MIR inlining, but I doubt this matters in practice, and fixes a beta regression, so let's fix it. I will look into approaches for fixing this in a more maintainable way, perhaps delaying the creation of drop shim bodies until codegen (like how intrinsics work).
Enable const casting for `f16` and `f128`
I have an open PR to the Miri repo adding tests for this behavior https://github.com/rust-lang/miri/pull/3688, but that unfortunately hits the ICE path here. The changes seem reasonably low risk that it might be okay to merge separately from the tests, and I tested the result locally against an older version of https://github.com/rust-lang/miri/pull/3688.
Cc ``````@RalfJung``````
Switch back `non_local_definitions` lint to allow-by-default
This PR switch back (again) the `non_local_definitions` lint to allow-by-default as T-lang is requesting some (major) changes in the lint inner workings in https://github.com/rust-lang/rust/issues/126768#issuecomment-2192634762.
This PR will need to be beta-backported, as the lint is currently warn-by-default in beta.
Update AST validation module docs
Drive-by doc update for AST validation pass:
- Syntax extensions are replaced by proc macros.
- Add rationale for why AST validation pass need to be run
post-expansion and why the pass is needed in the first place.
This was discussed during this week's [rustc-dev-guide reading club](https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-rustc-dev-guide), and the rationale was explained by cc ``````@bjorn3.``````
Instead of keeping a list of architectures which have native support
for 64-bit atomics, just use #[cfg(target_has_atomic = "64")] and its
inverted counterpart to determine whether we need to use portable
AtomicU64 on the target architecture.
Tighten `fn_decl_span` for async blocks
Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on #125078, but it fixes the problem in a more general way.
I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.
r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
Support fetching `Attribute` of items.
Fixes [https://github.com/rust-lang/project-stable-mir/issues/83](https://github.com/rust-lang/project-stable-mir/issues/83)
`rustc_ast::ast::Attribute` doesn't impl `Hash` and `Eq`. Thus it cannot be directly used as key of `IndexMap` in `rustc_smir::rustc_smir::Tables` and we cannot define stable `Attribute` as index to `rustc_ast::ast::Attribute` like `Span` and many other stable definitions.
Since an string (or tokens) and its span contain all info about an attribute, I defined a simple `Attribute` struct on stable side.
I choose to fetch attributes via `tcx::get_attrs_by_path()` due to `get_attrs()` is marked as deprecated and `get_attrs_by_name()` cannot handle name of multiple segments like `rustfmt::skip`.
r? `@celinval`
patchable-function-entry: Add unstable compiler flag and attribute
Tracking issue: #123115
Add the -Z patchable-function-entry compiler flag and the #[patchable_function_entry(prefix_nops = m, entry_nops = n)] attribute.
Rebased and adjusted the canditate implementation to match changes in the RFC.
ast: Standardize visiting order
Order: ID, attributes, inner nodes in source order if possible, tokens, span.
Also always use exhaustive matching in visiting infra, and visit some discovered missing nodes.
Unlike https://github.com/rust-lang/rust/pull/125741 this shouldn't affect anything serious like `macro_rules` scopes.
