Map RPIT duplicated lifetimes back to fn captured lifetimes
Use the [`lifetime_mapping`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping) to map an RPIT's captured lifetimes back to the early- or late-bound lifetimes from its parent function. We may be going thru several layers of mapping, since opaques can be nested, so we introduce `TyCtxt::map_rpit_lifetime_to_fn_lifetime` to loop through several opaques worth of mapping, and handle turning it into a `ty::Region` as well.
We can then use this instead of the identity substs for RPITs in `check_opaque_meets_bounds` to address #114285.
We can then also use `map_rpit_lifetime_to_fn_lifetime` to properly install bidirectional-outlives predicates for both RPITs and RPITITs. This addresses #114601.
I based this on #114574, but I don't actually know how much of that PR we still need, so some code may be redundant now... 🤷
---
Fixes#114597Fixes#114579Fixes#114285
Also fixes#114601, since it turns out we had other bugs with RPITITs and their duplicated lifetime params 😅.
Supersedes #114574
r? `@oli-obk`
[rustc_data_structures][base_n][perf] Remove unnecessary utf8 check.
Since all output characters taken from `BASE_64` are valid UTF8 chars there is no need to waste cycles on validation.
Even though it's obviously a perf win, I've also used a [benchmark](https://gist.github.com/ttsugriy/e1e63c07927d8f31e71695a9c617bbf3) on M1 MacBook Air with following results:
```
Running benches/base_n_benchmark.rs (target/release/deps/base_n_benchmark-825fe5895b5c2693)
push_str/old time: [14.670 µs 14.852 µs 15.074 µs]
Found 11 outliers among 100 measurements (11.00%)
4 (4.00%) high mild
7 (7.00%) high severe
push_str/new time: [12.573 µs 12.674 µs 12.801 µs]
Found 11 outliers among 100 measurements (11.00%)
7 (7.00%) high mild
4 (4.00%) high severe
```
rustc_interface: Dismantle `register_plugins` query
It did three independent things:
- Constructed `LintStore`
- Prepared incremental directories and dep graph
- Initialized some fields in `Session`
The `LintStore` construction (now `passes::create_lint_store`) is more or less left in place.
The incremental stuff is now moved into `fn dep_graph_future`.
This helps us to start loading the dep graph a bit earlier.
The `Session` field initialization is moved to tcx construction point.
Now that tcx is constructed early these fields don't even need to live in `Session`, they can live in tcx instead and be initialized at its creation (see the FIXME).
Three previously existing `rustc_interface` queries are de-querified (`register_plugins`, `dep_graph_future`, `dep_graph`) because they are only used locally in `fn global_ctxt` and their results don't need to be saved elsewhere.
On the other hand, `crate_types` and `stable_crate_id` are querified.
They are used from different places and their use is very similar to the existing `crate_name` query in this regard.
Structurally normalize weak and inherent in new solver
It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀
**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.
r? `@lcnr`
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
Remove arm crypto target feature
Follow-up to https://github.com/rust-lang/stdarch/pull/1407.
LLVM has moved away from a combined `crypto` feature on both aarch64 and arm, and we did the same on aarch64, but were deferred from doing the same on arm due to compatibility with older LLVM.
As the minimum LLVM version has increased, we can now remove this (unstable) target feature on arm.
r? `@Amanieu`
Warn when #[macro_export] is applied on decl macros
The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.
This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.
- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0
Avoid exporting __rust_alloc_error_handler_should_panic more than once.
Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined`
Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`. Builds with `ld.bfd` and `lld` should be unaffected.
http://errors.yoctoproject.org/Errors/Details/708194/
Fix#90546 by filtering out global value function pointer types from the
type tests, and adding the LowerTypeTests pass to the rustc LTO
optimization pipelines.
The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.
This commit adds the required error message in rustc_passes/messages.ftl,
as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.
Rollup of 9 pull requests
Successful merges:
- #113568 (Fix spurious test failure with `panic=abort`)
- #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
- #114485 (Add trait decls to SMIR)
- #114495 (Set max_atomic_width for AVR to 16)
- #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
- #114510 (llvm-wrapper: adapt for LLVM API changes)
- #114562 (stabilize abi_thiscall)
- #114570 ([miri][typo] Fix a typo in a vector_block comment.)
- #114573 (CI: do not hide error logs in a group)
r? `@ghost`
`@rustbot` modify labels: rollup
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
Make `unconditional_recursion` warning detect recursive drops
Closes#55388
Also closes#50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965.
r? `@oli-obk` since you are the mentor for #55388
Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.
`@rustbot` label +T-compiler +C-enhancement +A-lint
Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
Rollup of 6 pull requests
Successful merges:
- #114535 (bump schannel, miow to drop windows-sys 0.42)
- #114542 (interpret: use ConstPropNonsense for more const-prop induced issues)
- #114543 (add tests for some fixed ConstProp ICEs)
- #114550 (Generate better function argument names in global_allocator expansion)
- #114556 (Issue numbers are enforced on active features; remove FIXME)
- #114558 (Remove FIXME about NLL diagnostic that is already improved)
Failed merges:
- #114485 (Add trait decls to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
Issue numbers are enforced on active features; remove FIXME
Since https://github.com/rust-lang/rust/pull/51090 tidy enforces that active features have an issue number, so remove the FIXME.
This PR is part of #44366 which is E-help-wanted.
Steal MIR for CTFE when possible.
Some bodies, like constants, have CTFE MIR but no optimized MIR.
In that case, have `mir_for_ctfe` steal the MIR instead of cloning it.
Add documentation to has_deref
Documentation of `has_deref` needed some polish to be more clear about where it should be used and what's it's purpose.
cc https://github.com/rust-lang/rust/issues/114401
r? `@RalfJung`
Consolidate opaque ty and async fn lowering code
The codepaths for lowering "regular" opaques and async fn were almost identical, modulo some bookkeeping that seemed pretty easy to consolidate.
r? `@cjgillot`
Also ICE when goals go from Ok to Err in new solver
We were just using `?` here, silently downgrading the goal's response from (presumably) maybe to error -- that seems concerning, since this whole check is for detecting goal instability 😅
r? `@lcnr` or `@BoxyUwU`
Avoid invalid NaN lint machine-applicable suggestion in const context
This PR removes the machine-applicable suggestion in const context for the `invalid_nan_comparision` lint ~~and replace it with a simple help~~.
Fixes https://github.com/rust-lang/rust/issues/114471
Fix missing dependency file with `-Zunpretty`
This PR force the `output_filenames` to be run ~~in every early exits like~~ when using `-Zunpretty`, so to respect the `dep-info` flag.
Fixes https://github.com/rust-lang/rust/issues/112898
r? `@oli-obk`
Resolve visibility paths as modules not as types.
Asking for a resolution with `opt_ns = Some(TypeNS)` allows path resolution to look for type-relative paths, leaving unresolved segments behind. However, for visibility paths we really need to look for a module, so we need to pass `opt_ns = None`.
Fixes https://github.com/rust-lang/rust/issues/109146
r? `@petrochenkov`
Do not run ConstProp on mir_for_ctfe.
This pass does not seem to be useful any more. The const-prop lints are now run by `tcx.mir_drops_elaborated_and_const_checked`, and the const-prop opt should never emit any diagnostic.
Convert builtin "global" late lints to run per module
The compiler currently has 4 non-incremental lints:
1. `clashing_extern_declarations`;
2. `missing_debug_implementations`;
3. ~`unnameable_test_items`;~ changed by https://github.com/rust-lang/rust/pull/114414
4. `missing_docs`.
Non-incremental lints get reexecuted for each compilation, which is slow. Moreover, those lints are allow-by-default, so run for nothing most of the time. This PR attempts to make them more incremental-friendly.
`clashing_extern_declarations` is moved to a standalone query.
`missing_debug_implementation` can use `non_blanket_impls_for_ty` instead of recomputing it.
`missing_docs` is harder as it needs to track if there is a `doc(hidden)` module surrounding. I hack around this using the lint level engine. That's easy to implement and allows to re-enable the lint for a re-exported module, while a more proper solution would reuse the same device as `unnameable_test_items`.
Rollup of 5 pull requests
Successful merges:
- #114287 (update overflow handling in the new trait solver)
- #114475 (Migrate GUI colors test to original CSS color format)
- #114482 (Fix ui-fulldeps missing the `internal_features` lint on stage 0)
- #114490 (Fix a typo in the error reporting for sealed traits.)
- #114491 (Rename issue #114423 test files to include context)
r? `@ghost`
`@rustbot` modify labels: rollup
update overflow handling in the new trait solver
implements https://hackmd.io/QY0dfEOgSNWwU4oiGnVRLw?view. I want to clean up this doc and add it to the rustc-dev-guide, but I think this PR is ready for merge as is, even without the dev-guide entry.
r? `@compiler-errors`
Re-enable atomic loads and stores for all RISC-V targets
This roughly reverts PR https://github.com/rust-lang/rust/pull/66548
Atomic "CAS" are still disabled for targets without the *“A” Standard Extension for Atomic Instructions*. However this extension only adds instructions for operations more complex than simple loads and stores, which are always atomic when aligned.
In the [Unprivileged Spec v. 20191213](https://riscv.org/technical/specifications/) section 2.6 *Load and Store Instructions* of chapter 2 *RV32I Base Integer Instruction Set* (emphasis mine):
> Even when misaligned loads and stores complete successfully, these accesses might run extremely slowly depending on the implementation (e.g., when implemented via an invisible trap). Further-more, whereas **naturally aligned loads and stores are guaranteed to execute atomically**, misaligned loads and stores might not, and hence require additional synchronization to ensure atomicity.
Unfortunately PR https://github.com/rust-lang/rust/pull/66548 did not provide much details on the bug that motivated it, but https://github.com/rust-lang/rust/issues/66240 and https://github.com/rust-lang/rust/issues/85736 appear related and happen with targets that do have the A extension.
Add separate feature gate for async fn track caller
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes#110009
Improve spans for indexing expressions
fixes#114388
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
r? compiler-errors
[rustc_span][perf] Remove unnecessary string joins and allocs.
Comparing vectors of string parts yields the same result but avoids unnecessary `join` and potential allocation for resulting `String`. This code is cold so it's unlikely to have any measurable impact, but considering but since it's also simpler, why not? :)
Lots of tiny incremental simplifications of `EmitterWriter` internals
ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version.
Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them.
After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects
```
error[E0599]: no method named `x` found for struct `Pin<&S>` in the current scope
--> $DIR/arbitrary_self_type_mut_difference.rs:11:18
|
LL | Pin::new(&S).x();
| ^ help: there is a method with a similar name: `y`
|
note: method is available for `Pin<&mut S>`
--> $DIR/arbitrary_self_type_mut_difference.rs:6:5
|
LL | fn x(self: Pin<&mut Self>) {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Related to #57994, as one of the presented cases can lead to code like
this.
This deduplicates some logic and makes it easier to follow what wrappers
are produced. In the future it may allow moving the code to determine
which wrappers to create to cg_ssa.
Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.
Rework upcasting confirmation to support upcasting to fewer projections in target bounds
This PR implements a modified trait upcasting algorithm that is resilient to changes in the number of associated types in the bounds of the source and target trait objects.
It does this by equating each bound of the target trait ref individually against the bounds of the source trait ref, rather than doing them all together by constructing a new trait object.
#### The new way we do trait upcasting confirmation
1. Equate the target trait object's principal trait ref with one of the supertraits of the source trait object's principal.
fdcab310b2/compiler/rustc_trait_selection/src/traits/select/mod.rs (L2509-L2525)
2. Make sure that every auto trait in the *target* trait object is present in the source trait ref's bounds.
fdcab310b2/compiler/rustc_trait_selection/src/traits/select/mod.rs (L2559-L2562)
3. For each projection in the *target* trait object, make sure there is exactly one projection that equates with it in the source trait ref's bound. If there is more than one, bail with ambiguity.
fdcab310b2/compiler/rustc_trait_selection/src/traits/select/mod.rs (L2526-L2557)
* Since there may be more than one that applies, we probe first to check that there is exactly one, then we equate it outside of a probe once we know that it's unique.
4. Make sure the lifetime of the source trait object outlives the lifetime of the target.
<details>
<summary>Meanwhile, this is how we used to do upcasting:</summary>
1. For each supertrait of the source trait object, take that supertrait, append the source object's projection bounds, and the *target* trait object's auto trait bounds, and make this into a new object type:
d12c6e947c/compiler/rustc_trait_selection/src/traits/select/confirmation.rs (L915-L929)
2. Then equate it with the target trait object:
d12c6e947c/compiler/rustc_trait_selection/src/traits/select/confirmation.rs (L936)
This will be a type mismatch if the target trait object has fewer projection bounds, since we compare the bounds structurally in relate:
d12c6e947c/compiler/rustc_middle/src/ty/relate.rs (L696-L698)
</details>
Fixes#114035
Also fixes#114113, because I added a normalize call in the old solver.
r? types
resolve before canonicalization in new solver, ICE if unresolved
Fold the values with a resolver before canonicalization instead of making it happen within canonicalization.
This allows us to filter trivial region constraints from the external constraints.
r? ``@lcnr``
Perform OpaqueCast field projection on HIR, too.
fixes#105819
This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field).
See https://github.com/rust-lang/rust/pull/99806 for when and why we added OpaqueCast to MIR.
cg_llvm: stop identifying ADTs in LLVM IR
This is an extension of https://github.com/rust-lang/rust/pull/94107. It may be a minor perf win.
Fixes#96242.
Now that we use opaque pointers, ADTs can no longer be recursive, so we
do not need to name them. Previously, this would be necessary if you had
a struct like
```rs
struct Foo(Box<Foo>, u64, u64);
```
which would be represented with something like
```ll
%Foo = type { %Foo*, i64, i64 }
```
which is now just
```ll
{ ptr, i64, i64 }
```
r? `@tmiasko`
Enable tests on rustc_codegen_ssa
This enables unittests in rustc_codegen_ssa. There are some tests, primarily in [`back/rpath/tests.rs`](https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_codegen_ssa/src/back/rpath/tests.rs) that haven't ever been running since the unittests are disabled. From what I can tell, this was just a consequence of how things evolved. When testing was initially added in https://github.com/rust-lang/rust/pull/33282, `librustc_trans` had test=false because it didn't have any tests. `rustc_codegen_ssa` eventually split off from that (https://github.com/rust-lang/rust/pull/55627), and the rpath module eventually got merged in too (from `librustc_back` where it used to live). That migration didn't enable the tests.
This also includes some fluent diagnostic tests, though I'm not sure what exactly they are testing.
Forbid old-style `simd_shuffleN` intrinsics
Don't merge before https://github.com/rust-lang/packed_simd/pull/350 has made its way to crates.io
We used to support specifying the lane length of simd_shuffle ops by attaching the lane length to the name of the intrinsic (like `simd_shuffle16`). After this PR, you cannot do that anymore, and need to instead either rely on inference of the `idx` argument type or specify it as `simd_shuffle::<_, [u32; 16], _>`.
r? `@workingjubilee`
Only unpack tupled args in inliner if we expect args to be unpacked
`"rust-call"` is a strange function abi. sometimes, it expects the arguments to be unpacked by the caller and passed as individual args (closure bodies), and sometimes it does not (user functions annotated with the `"rust-call"` abi).
make sure the mir inliner respects this difference when checking that arguments are compatible, and doesn't try to ICE when we call a `extern "rust-call"` function in a generic context.
fixes#110829
Add `internal_features` lint
Implements https://github.com/rust-lang/compiler-team/issues/596
Also requires some more test blessing for codegen tests etc
`@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.
const validation: point at where we found a pointer but expected an integer
Instead of validation just printing "unable to turn pointer into bytes", make this a regular validation error that says where in the value the bad pointer was found. Also distinguish "expected integer, got pointer" from "expected pointer, got partial pointer or mix of pointers".
To avoid duplicating things too much I refactored the diagnostics for validity a bit, so that "got uninit, expected X" and "got pointer, expected X" can share the "X" part. Also all the errors emitted for validation are now grouped under `const_eval_validation` so that they are in a single group in the ftl file.
r? `@oli-obk`
parser: more friendly hints for handling `async move` in the 2015 edition
Fixes#114219
An error is emitted when encountering an async move block in the 2015 edition.
Another appropriate location to raise an error is after executing [let path = this.parse_path(PathStyle::Expr)?](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/stmt.rs#L152), but it seems somewhat premature to invoke `create_err` at that stage.
Expand, rename and improve `incorrect_fn_null_checks` lint
This PR,
- firstly, expand the lint by now linting on references
- secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks`
- and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut`
Fixes https://github.com/rust-lang/rust/issues/113601
cc ```@est31```
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
Infer type in irrefutable slice patterns with fixed length as array
Fixes https://github.com/rust-lang/rust/issues/76342
In irrefutable slice patterns with a fixed length, we can infer the type as an array type. We now choose to prefer some implementations over others, e.g. in:
```
struct Zeroes;
const ARR: [usize; 2] = [0; 2];
const ARR2: [usize; 2] = [2; 2];
impl Into<&'static [usize; 2]> for Zeroes {
fn into(self) -> &'static [usize; 2] {
&ARR
}
}
impl Into<&'static [usize]> for Zeroes {
fn into(self) -> &'static [usize] {
&ARR2
}
}
fn main() {
let &[a, b] = Zeroes.into();
}
```
We now prefer the impl candidate `impl Into<&'static [usize; 2]> for Zeroes`, it's not entirely clear to me that this is correct, but given that the slice impl would require a type annotation anyway, this doesn't seem unreasonable.
r? `@lcnr`
Fix suggestion spans for expr from macro expansions
### Issue #112007: rustc shows expanded `writeln!` macro in code suggestion
#### Before This PR
```
help: consider using a semicolon here
|
6 | };
| +
help: you might have meant to return this value
--> C:\Users\hayle\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\macros\mod.rs:557:9
|
55| return $dst.write_fmt($crate::format_args_nl!($($arg)*));
| ++++++ +
```
#### After This PR
```
help: consider using a semicolon here
|
LL | };
| +
help: you might have meant to return this value
|
LL | return writeln!(w, "but not here");
| ++++++ +
```
### Issue #110017: `format!` `.into()` suggestion deletes the `format` macro
#### Before This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
--> /Users/eric/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/macros.rs:121:12
|
12| res.into()
| +++++++
```
#### After This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
|
LL | Err(format!("error: {x}").into())
| +++++++
```
---
Fixes#112007.
Fixes#110017.
Miscellaneous HIR typeck nits
Remove some check functions that only have one usage
Also remove `Expectation::IsLast`, which was both undocumented, and was also made redundant by my cleanup/fix in #103987😸
Suggest `x build library` for a custom toolchain that fails to load `core`
Fixes#113222
The nicer suggestion for dev-channel won't be emitted if `-Z ui-testing` enabled. IMO, this is acceptable for now.
It's the same as `Delimiter`, minus the `Invisible` variant. I'm
generally in favour of using types to make impossible states
unrepresentable, but this one feels very low-value, and the conversions
between the two types are annoying and confusing.
Look at the change in `src/tools/rustfmt/src/expr.rs` for an example:
the old code converted from `MacDelimiter` to `Delimiter` and back
again, for no good reason. This suggests the author was confused about
the types.
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes#110009
Exporting `__rust_alloc_error_handler_should_panic` multiple times
causes ld.gold to balk with: `error: version script assignment of to
symbol __rust_alloc_error_handler_should_panic failed: symbol not
defined`
Specifically this breaks builds on DragonFly and YoctoProject with
ld.gold. Builds with ld.bfd should be unaffected.
Rollup of 5 pull requests
Successful merges:
- #114079 (Use `upvar_tys` in more places, make it return a list)
- #114166 (Add regression test for resolving `--extern libc=test.rlib`)
- #114321 (get auto traits for parallel rustc)
- #114335 (fix and extend ptr_comparison test)
- #114347 (x.py print more detailed format files and untracked files count)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve `invalid_reference_casting` lint
This PR is a follow-up to https://github.com/rust-lang/rust/pull/111567 and https://github.com/rust-lang/rust/pull/113422.
This PR does multiple things:
- First it adds support for deferred de-reference, the goal is to support code like this, where the casting and de-reference are not done on the same expression
```rust
let myself = self as *const Self as *mut Self;
*myself = Self::Ready(value);
```
- Second it does not lint anymore on SB/TB UB code by only checking assignments (`=`, `+=`, ...) and creation of mutable references `&mut *`
- Thirdly it greatly improves the diagnostics in particular for cast from `&mut` to `&mut` or assignments
- ~~And lastly it renames the lint from `cast_ref_to_mut` to `invalid_reference_casting` which is more consistent with the ["rules"](https://github.com/rust-lang/rust-clippy/issues/2845) and also more consistent with what the lint checks~~ *https://github.com/rust-lang/rust/pull/113422*
This PR is best reviewed commit by commit.
r? compiler
Miri: fix error on dangling pointer inbounds offset
We used to claim that the pointer was "dereferenced", but that is just not true.
Can be reviewed commit-by-commit. The first commit is an unrelated rename that didn't seem worth splitting into its own PR.
r? `@oli-obk`
coverage: Consolidate FFI types into one module
Coverage FFI types were historically split across two modules, because some of them were needed by code in `rustc_codegen_ssa`.
Now that all of the coverage codegen code has been moved into `rustc_codegen_llvm` (#113355), it's possible to move all of the FFI types into a single module, making it easier to see all of them at once.
---
This PR only moves code and adjusts imports; there should be no functional changes.
Coverage FFI types were historically split across two modules, because some of
them were needed by code in `rustc_codegen_ssa`.
Now that all of the coverage codegen code has been moved into
`rustc_codegen_llvm` (#113355), it's possible to move all of the FFI types into
a single module, making it easier to see all of them at once.
Rollup of 6 pull requests
Successful merges:
- #114178 (Account for macros when suggesting a new let binding)
- #114199 (Don't unsize coerce infer vars in select in new solver)
- #114301 (Don't check unnecessarily that impl trait is RPIT)
- #114314 (Tweaks to `adt_sized_constraint`)
- #114322 (Fix invalid slice coercion suggestion reported in turbofish)
- #114340 ([rustc_attr][nit] Replace `filter` + `is_some` with `map_or`.)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix invalid slice coercion suggestion reported in turbofish
This PR fixes the invalid slice coercion suggestion reported in turbofish and inferred generics by not emitting them.
Fixes https://github.com/rust-lang/rust/issues/110063
Don't check unnecessarily that impl trait is RPIT
We have this random `return_type_impl_trait` function to detect if a function returns an RPIT which is used in outlives suggestions, but removing it doesn't actually change any diagnostics. Let's just remove it.
Also, suppress a spurious outlives error from a ReError.
Fixes#114274
Account for macros when suggesting a new let binding
Provide a structured suggestion when the expression comes from a macro expansion:
```
error[E0716]: temporary value dropped while borrowed
--> $DIR/borrowck-let-suggestion.rs:2:17
|
LL | let mut x = vec![1].iter();
| ^^^^^^^ - temporary value is freed at the end of this statement
| |
| creates a temporary value which is freed while still in use
LL |
LL | x.use_mut();
| - borrow later used here
|
= note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider using a `let` binding to create a longer lived value
|
LL ~ let binding = vec![1];
LL ~ let mut x = binding.iter();
|
```
WASI threads, implementation of wasm32-wasi-preview1-threads target
This PR adds a target proposed in https://github.com/rust-lang/compiler-team/issues/574 by `@abrown` and implementation of `std:🧵:spawn` for the target `wasm32-wasi-preview1-threads`
### Tier 3 Target Policy
As tier 3 targets, the new targets are required to adhere to [the tier 3 target policy](https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy) requirements. This section quotes each requirement in entirety and describes how they are met.
> - A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/pull/112922/files#diff-a48ee9d94f13e12be24eadd08eb47b479c153c340eeea4ef22276d876dfd4f3e).
> - Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
> - Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
The target is using the same name for $ARCH=wasm32 and $OS=wasi as existing Rust targets. The suffix `preview1` introduced to accurately set expectations because eventually this target will be deprecated and follows [MCP 607](https://github.com/rust-lang/compiler-team/issues/607). The suffix `threads` indicates that it’s an extension that enables threads to the existing target and it follows [MCP 574](https://github.com/rust-lang/compiler-team/issues/574) which describes the rationale behind introducing a separate target.
> - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
> - The target must not introduce license incompatibilities.
> - Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
> - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
This PR does not introduce any new dependency.
The new target doesn’t support building host tools.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
The full standard library is available for this target as it’s an extension to an existing target that has already supported it.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Only manual test running is supported at the moment with some tweaks in the test runner codebase. For build and running tests see [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/pull/112922/files#diff-a48ee9d94f13e12be24eadd08eb47b479c153c340eeea4ef22276d876dfd4f3e).
> - Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> - This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
> - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> - Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
> - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> - In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
I acknowledge these requirements and intend to ensure they are met.
Similar to the last commit, it's more of a `Parser`-level concern than a
`TokenCursor`-level concern. And the struct size reductions are nice.
After this change, `TokenCursor` is as minimal as possible (two fields
and two methods) which is nice.
It's more of a `Parser`-level concern than a `TokenCursor`-level
concern. Also, `num_bump_calls` is a more accurate name, because it's
incremented in `Parser::bump`.
Comparing vectors of string parts yields the same result but avoids
unnecessary `join` and potential allocation for resulting `String`.
This code is cold so it's unlikely to have any measurable impact, but
considering but since it's also simpler, why not? :)
Filter out short-lived LLVM diagnostics before they reach the rustc handler
During profiling I saw remark passes being unconditionally enabled: for example `Machine Optimization Remark Emitter`.
The diagnostic remarks enabled by default are [from missed optimizations and opt analyses](https://github.com/rust-lang/rust/pull/113339#discussion_r1259480303). They are created by LLVM, passed to the diagnostic handler on the C++ side, emitted to rust, where they are unpacked, C++ strings are converted to rust, etc.
Then they are discarded in the vast majority of the time (i.e. unless some kind of `-Cremark` has enabled some of these passes' output to be printed).
These unneeded allocations are very short-lived, basically only lasting between the LLVM pass emitting them and the rust handler where they are discarded. So it doesn't hugely impact max-rss, and is only a slight reduction in instruction count (cachegrind reports a reduction between 0.3% and 0.5%) _on linux_. It's possible that targets without `jemalloc` or with a worse allocator, may optimize these less.
It is however significant in the aggregate, looking at the total number of allocated bytes:
- it's the biggest source of allocations according to dhat, on the benchmarks I've tried e.g. `syn` or `cargo`
- allocations on `syn` are reduced by 440MB, 17% (from 2440722647 bytes total, to 2030461328 bytes)
- allocations on `cargo` are reduced by 6.6GB, 19% (from 35371886402 bytes total, to 28723987743 bytes)
Some of these diagnostics objects [are allocated in LLVM](https://github.com/rust-lang/rust/pull/113339#discussion_r1252387484) *before* they're emitted to our diagnostic handler, where they'll be filtered out. So we could remove those in the future, but that will require changing a few LLVM call-sites upstream, so I left a FIXME.
Move doc comment desugaring out of `TokenCursor`.
It's awkward that `TokenCursor` sometimes desugars doc comments on the fly, but usually doesn't.
r? `@petrochenkov`
now that remarks are filtered before cg_llvm's diagnostic handler callback
is called, we don't need to do the filtering post c++-to-rust conversion
of the diagnostic.
this will eliminate many short-lived allocations (e.g. 20% of the memory used
building cargo) when unpacking the diagnostic and converting its various
C++ strings into rust strings, just to be filtered out most of the time.
