Revert tearing changes to `dbg!`
Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions:
* rust-lang/rust#153850, fixed by rust-lang/rust#154074
* rust-lang/rust#154988, fixed by rust-lang/rust#154994
* rust-lang/rust#155902, proposed fix in rust-lang/rust#155915
We already reverted this once, on beta only to prevent these regressions from shipping in 1.95.
In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one.
cc @joboet @dianne @rust-lang/libs
@rustbot label beta-nominated
Make bitset `would_modify_words` more vectorizer-friendly
Currently this function compares a single pair of `u64` at a time, which is potentially slower than comparing multiple words before each early-exit check, especially for the large chunks used by ChunkedBitSet.
Perf shows a notable improvement in `cranelift-codegen`, which is the one benchmark that is known to stress these code paths.
- Incorporates https://github.com/rust-lang/rust/pull/153759.
Add support for xray in aarch64 unknown none targets
I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile.
I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`.
Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want.
I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`.
I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do.
As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options.
It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library.
I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.
Privacy: try use queue instead of fixed-point iteration
Earlier: iterate until updates of `EffectiveVisibility` occur.
Now: if an update occurs, then we put in the queue those items that may be affected by this update. Iterate until there are items in the queue.
r? @petrochenkov
test new solver on CI until stabilization
We need the new solver to be able to build the stdlib, and this has regressed in the recent past. Things are broken right now, and we want to ensure this keeps working until stabilization later this year.
I've added this to the `x86_64-gnu-llvm-XX` job (note no `-1/2/3` suffix) so it's run on PR and auto CI, and because it's roughly the fastest of these builders, though maybe the aarch64 llvm 1 and 2 are slightly faster.
Building the stage 1 `./x build library/` is generally quite quick, a couple minutes at most.
The new solver fix to build std is from @lcnr [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/weekly.20sync.2Fupdates/near/591998234).
r? @marcoieni
Fix invalid suggestion for parenthesized break
Resolvesrust-lang/rust#156383
The old code incorrectly assumed `e.span` started exactly at the beginning of `break`. Fixed by locating the exact start position of `break`.
Allow `global_asm!` in statement positions
This PR makes it possible to put `global_asm!` in statement positions. This is particularly useful for proc-macros, where you otherwise have to wrap them in `mod foo { global_asm!(...); }`.
I'm happy to open an ACP first (or a design meeting?).
I would also assume this needs sign-off from the lang-team?
Previously discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/216763-project-inline-asm/topic/Item.20position.20global_asm/with/581784943).
r? @Amanieu
Avoid const generic recovery after doc comment in type
Fixesrust-lang/rust#122463.
When parsing a generic argument, rustc may snapshot the parser state and retry a failed type parse as an unbraced const generic argument. For `Vec<(/// doc
f32, f32)>`, that recovery produces a misleading follow-up E0747 after the useful “expected type, found doc comment” diagnostic.
This skips that const-generic recovery path when type parsing stopped at a doc comment, and adds a regression test for the compiler diagnostic.
delegation: visit path under elided-infer lifetime rib
Up to this moment we processed delegation path under `LifetimeRibKind::Generics` which is not correct as we are processing generic args of a future call, not generic params. In this PR we visit path under
`LifetimeRibKind::Elided(LifetimeRes::Infer)`.
Fixesrust-lang/rust#156342. Part of rust-lang/rust#118212.
r? @petrochenkov
rename unexpected_try_recover function
While reading the code, the doc comment and the name of the function `unexpected_try_recover` confused me. The doc said it tries to recover if it is a closing delimiter but I see no recovering code and the function always return an error.
So I change the name of the function to `unexpected_err` and change the return value to `Diag<'a>`. I also update the doc comment.
Avoid rustfix suggestions for macro-expanded unused imports
Avoid emitting rustfix suggestions for unused imports when the removal span is not directly editable.
Closesrust-lang/rust#147855
Split `LintExpectationId`s
This PR makes clearer where stable and unstable `LintExpectationIds` can occur, plus a few other small cleanups. Details in individual commits.
r? @GuillaumeGomez
compiler: suggest `.collect()` when `String` is expected and `Iterator` is found
This commit adds a diagnostic suggestion to help users who forget to call `.collect()` when they have an iterator and the function or variable expects a `String`.
The logic checks if the expected type is `std::string::String` and if the found type implements the `Iterator` trait, if so the compiler provides a suggestion to add `.collect()`
Includes also a UI test to verify if the suggestion appears correctly
Remove redundant information in `rustc_abi::Variants`
Follow-up to rust-lang/rust#151040; partially addresses rust-lang/rust#113988.
Replaces the nested `LayoutData` in `Variants::Multiple` by a new, smaller `VariantLayout` struct, and adjust `LayoutData::for_variant`and the layout algorithm in consequence.
This PR is best reviewed commit-by-commit.
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
`LintExpectationId` has two variants, `Unstable` and `Stable`. There are
some places where both variants are possible, but there are also places
where only one of `Unstable` or `Stable` is possible.
This commit encodes this into the type system by introducing
new types `UnstableLintExpectationId` and `StableLintExpectationId`. The
variants of `LintExpectationId` now enclose these. This makes it clearer
what values are possible where.
Other things of note:
- `LintLevelsProvider` gets an associated type and some method changes.
- `LintContext` gets an associated type.
- `LevelSpec` is made generic. `UnstableLevelSpec` and `StableLevelSpec`
typedefs are added.
- The unstable types are now guaranteed by the type system to never be
stably hashed. Previously this was a runtime check.
delegation: emit error when self type is not specified and accessed
This PR adds error reporting when we create error self type if it was not specified. In most of the tests there were other errors, so this delayed bug was not triggered, but there are cases like `reuse Default::default;` (rust-lang/rust#156388) which does not emit other errors and those delayed bugs are triggered.
Part of rust-lang/rust#118212. Fixesrust-lang/rust#156388.
r? @petrochenkov
Disable `main_needs_argc_argv` for Wasm
AFAIU this explains to the "Rust Runtime" that `main()` doesn't need `argc`/`argv`. Newer Wasm targets have explicitly disabled this, this PR changes it so that the base Wasm configuration affecting all Wasm targets disables this now.
This affects the following targets:
- `wasm32-unknown-unknown`
- `wasm32v1-none`
- `wasm64-unknown-unknown`
The only Wasm target where `main_needs_argc_argv` is still enabled is `wasm32-unknown-emscripten`. @hoodmane let me know and I can remove it there as well.
Credit goes to @Spxg for stumbling on this.
r? @alexcrichton
Allow user-provided `llvm_args` to override target spec arguments
This switches the order in which `-Cllvm-args` is applied between target-spec arguments and user-provided LLVM arguments.
This came up in rust-lang/rust#156061, where the target passing `-Cllvm-args=-wasm-use-legacy-eh=false` means that a user passing `-Cllvm-args=-wasm-use-legacy-eh=true` cannot override this value since the LLVM arguments support the last argument overriding the previous, and user arguments were chained first.
With this change, it is possible for Wasm targets to opt into legacy EH for compatibility with runtimes that don't yet implement the modern exnref/try_table instructions, such as Node.js 20 on V8 11.3 and older browsers. While Node.js 20 is formally EOL, many libraries will still need to support this version for a few months yet, so this would ease the transition path to modern exception handling having an opt-out.
Originally this PR added support for a dedicated `-Z` flag for switching to legacy exception handling, but fine-grained control over the arguments would be a preferable solution provided it does not conflict with other behaviours.
//cc @alexcrichton
Implement pinned drop sugar
Implements `fn drop(&pin mut self)` as sugar for `Drop::pin_drop`.
The resolver recognizes `fn drop(&pin mut self)` syntactically in trait impls and performs lookup using the effective `pin_drop` name. AST lowering independently rechecks the syntactic sugar, validates that the resolved item belongs to the actual `Drop` lang trait, and emits HIR with ident `pin_drop` for accepted sugar. Existing type checking, Drop validation, drop glue, and direct-call checks remain unchanged.
Drop identity is checked during AST lowering through `tcx.lang_items().drop_trait()`, after resolver has performed the effective `pin_drop` lookup. The resolver does not need to know whether the trait is the actual `Drop` lang item, and it no longer passes marked impl item IDs to lowering.
This intentionally preserves the base pinned-drop behavior where `#[pin_v2]` types must use `pin_drop`, while non-`#[pin_v2]` types may still implement `pin_drop`.
r? @petrochenkov
## Related
https://github.com/rust-lang/rust/pull/144537https://github.com/rust-lang/rust/issues/130494
Require EIIs to be defined when we compile a rust dylib
The linker will complain about undefined symbols otherwise and on object file formats with two level namespaces (Mach-O and PE/COFF) it is required to know which dylib a symbol will be imported from when linking a dylib or executable.
r? @jdonszelmann
DestinationPropagation: compute liveness as ranges instead of traveling bitsets
The current implementation of `save_as_liveness` is very slow, and consists in inserting a traveling bitset in an interval set.
As the `MaybeLiveLocals` has a gen-kill property, we can leverage it to make it faster. "Gen" is creating a new interval. "Kill" is ending this interval, ripe to save in the interval set.
bors