Async drop source info fix for proxy-drop-coroutine
Fixes crash at debug info generation: https://github.com/rust-lang/rust/issues/140426 .
Also, the submitted example requires sync Drop implementation too.
Because sync version is required for unwind and when drop is performed in sync context (sync function).
Probably, it is also needed to add such a lint/error about missed `impl Drop`, when there is `impl AsyncDrop`.
Fix description: even minimal, empty coroutine (for proxy-coroutine) has 3 states and the source info array should have 3 elements too.
```
#![feature(async_drop)]
use std::future::AsyncDrop;
use std::pin::Pin;
#[tokio::main(flavor = "current_thread")]
async fn main() {
let _st = St;
}
struct St;
impl AsyncDrop for St {
async fn drop(self: Pin<&mut Self>) {
println!("123");
}
}
```
Allow linking rustc and rustdoc against the same single tracing crate
Alternate title: _Ignore "a global default trace dispatcher has already been set" error in Rustdoc_
By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes that these involve 2 different tracing crates.
I would like to be able to build rustdoc against the same tracing crate that rustc_log is also built against. Previously this arrangement would crash rustdoc:
```console
thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65:
called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set")
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: rustc_log::init_logger
4: rustc_driver_impl::init_logger
5: rustdoc::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md
note: please make sure that you have updated to the latest nightly
query stack during panic:
end of query stack
```
Don't name variables from external macros in borrow errors.
This came up as part of the expansion of format_args. However, it's a more general problem (and now solution).
I noticed that this does change another test, moving out of fields in derives on packed struct. However, I think this is a better error simply because it used to refer to `other.0` which is an implementation detail which doesn't really make sense.
cc `@m-ou-se`
Rollup of 7 pull requests
Successful merges:
- #139675 (Add the AVX10 target features)
- #140286 (Check if format argument is identifier to avoid error err-emit)
- #140456 (Fix test simd/extract-insert-dyn on s390x)
- #140551 (Move some tests out of tests/ui)
- #140588 (Adjust some ui tests re. target-dependent errors)
- #140617 (Report the `unsafe_attr_outside_unsafe` lint at the closest node)
- #140626 (allow `#[rustfmt::skip]` in combination with `#[naked]`)
r? `@ghost`
`@rustbot` modify labels: rollup
allow `#[rustfmt::skip]` in combination with `#[naked]`
fixes https://github.com/rust-lang/rust/issues/140623
We very deliberately use an allowlist to prevent weird interactions with `#[naked]`, hopefully we've now found all of the useful combinations.
cc `@Amanieu`
Report the `unsafe_attr_outside_unsafe` lint at the closest node
This PR have `AstValidation` track a linting node id and then uses it when reporting the `unsafe_attr_outside_unsafe` lint, so that instead of being bound at the crate-root, `#[allow]` of the lint works at any node.
Fixesrust-lang/rust#140602
r? `@jieyouxu`
Check if format argument is identifier to avoid error err-emit
Fixes#139104
When `argument` is not an identifier, it should not be considered a field access. I checked this and if not emit an invalid format string error. I think we could do with a little finer error handling, I'll open an issue to track this down later.
The first commit submits the ui test, the second commits the code and the changes to the test output.
r? compiler
Add the AVX10 target features
Parent #138843
Adds the `avx10_target_feature` feature gate, and `avx10.1` and `avx10.2` target features.
It is confirmed that Intel is dropping AVX10/256 (see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2795442288)), so this should be safe to implement now.
The LLVM fix for llvm/llvm-project#135394 was merged, and has been backported to LLVM20, and the patch has also been propagated to rustc in #140502
`@rustbot` label O-x86_64 O-x86_32 A-target-feature A-SIMD
Set groundwork for proper const normalization
r? lcnr
Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented.
I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes
that these involve 2 different tracing crates.
I would like to be able to build rustdoc against the same tracing crate
that rustc_log is also built against. Previously this arrangement would
crash rustdoc:
thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65:
called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set")
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: rustc_log::init_logger
4: rustc_driver_impl::init_logger
5: rustdoc::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md
note: please make sure that you have updated to the latest nightly
query stack during panic:
end of query stack
resolve: Support imports of associated types and glob imports from traits
Follow up to https://github.com/rust-lang/rust/pull/134754, part of https://github.com/rust-lang/rust/issues/134691.
This PR also closes https://github.com/rust-lang/rust/issues/138711 now.
Prohibiting `use Trait::AssocType;` at name resolution stage doesn't make sense, the name itself is perfectly resolveable.
It's a type checker's problem that the necessary generic args are not passed when the imported `AssocType` is used, so an error should be reported there.
And since we can import associated trait items now, glob imports from traits can also be allowed.
Use a closure instead of three chained iterators
Fixes the perf regression from #123948
That PR had chained a third option to the iterator which apparently didn't optimize well
Emit user type annotations for free consts in pattern position
This previously wasnt done because free consts couldn't have any generic parameters that need to be preserved for borrowck. This is no longer the case with `feature(generic_const_items)`
r? fmease
PassWrapper: adapt for llvm/llvm-project@f137c3d592e96330e450a8fd63ef…
…7e8877fc1908
In LLVM 21 PR https://github.com/llvm/llvm-project/pull/130940 `TargetRegistry::createTargetMachine` was changed to take a `const Triple&` and has deprecated the old `StringRef` method.
``@rustbot`` label llvm-main
mono collector: Reduce # of locking while walking the graph
While profiling Zed's dev build I've noticed that while most of the time `upstream_monomorphizations` takes a lot of time in monomorpization_collector, in some cases (e.g. build of `editor` itself) the rest of monomorphization_collector_graph_walk dominates it. Most of the time is spent in collect_items_rec.
This PR aims to reduce the number of locks taking place; instead of locking output MonoItems once per children of current node, we do so once per *current node*. We also get to reuse locks for mentioned and used items. While this commit does not reduce Wall time of Zed's build, it does shave off CPU time (measured with `cargo build -j1`) from 48s to 47s. I've also tested it with parallel frontend against Zed and ripgrep and found no regressions.
Rollup of 9 pull requests
Successful merges:
- #140485 (Optimize the codegen for `Span::from_expansion`)
- #140509 (transmutability: merge contiguous runs with a common destination)
- #140519 (Use select in projection lookup in `report_projection_error`)
- #140521 (interpret: better error message for out-of-bounds pointer arithmetic and accesses)
- #140536 (Rename `*Guard::try_map` to `filter_map`.)
- #140550 (Stabilize `select_unpredictable`)
- #140563 (extend the list of registered dylibs on `test::prepare_cargo_test`)
- #140572 (Add useful comments on `ExprKind::If` variants.)
- #140574 (Add regression test for 133065)
r? `@ghost`
`@rustbot` modify labels: rollup
Use select in projection lookup in `report_projection_error`
Using `for_each_relevant_impl` doesn't actually select the correct impl; we can use `select` here to actually get the correct impl with certainty. Follow-up to https://github.com/rust-lang/rust/pull/140278.
r? oli-obk
Optimize the codegen for `Span::from_expansion`
See https://godbolt.org/z/bq65Y6bc4 for the difference. the new version is less than half the number of instructions.
Also tried fully writing the function by hand:
```rust
sp.ctxt_or_parent_or_marker != 0
&& (
sp.len_with_tag_or_marker == BASE_LEN_INTERNED_MARKER
|| sp.len_with_tag_or_marker & PARENT_TAG == 0
)
```
But that was no better than this PR's current use of `match_span_kind`.
