Implement a Method to Seal `DiagInner`'s Suggestions
This PR adds a method on `DiagInner` called `.seal_suggestions()` to prevent new suggestions from being added while preserving existing suggestions.
This is useful because currently there is no way to prevent new suggestions from being added to a diagnostic. `.disable_suggestions()` is the closest but it gets rid of all suggestions before and after the call.
Therefore, `.seal_suggestions()` can be used when, for example, misspelled keyword is detected and reported. In such cases, we may want to prevent other suggestions from being added to the diagnostic, as they would likely be meaningless once the misspelled keyword is identified. For context: https://github.com/rust-lang/rust/pull/129899#discussion_r1741307132
To store an additional state, the type of the `suggestions` field in `DiagInner` was changed into a three variant enum. While this change affects files across different crates, care was taken to preserve the existing code's semantics. This is validated by the fact that all UI tests pass without any modifications.
r? chenyukang
tests: allow trunc/select instructions to be missing
On LLVM 20, these instructions already get eliminated, which at least partially satisfies a TODO. I'm not talented enough at using FileCheck to try and constrain this further, but if we really want to we could copy an LLVM 20 specific version of this test that would restore it to being CHECK-NEXT: insertvalue ...
`@rustbot` label: +llvm-main
r? `@DianQK`
Remove redundant test typeid equality by subtyping
This known-bug label was a left over on #118247
r? `@jackh726`
This doesn't address #110395, I didn't investigate about it yet.
Remove uneeded PartialOrd bound in cmp::Ord::clamp
There is a `Self: PartialOrd` bound in `Ord::clamp`, but it is already required by the trait itself. Likely a left-over from the const trait deletion in 76dbe29104.
Reported-by: `@noeensarguet`
There is a Self: PartialOrd bound in Ord::clamp, but it is already
required by the trait itself. Likely a left-over from the const trait
deletion in 76dbe29104.
Reported-by: @noeensarguet
Use `@only-target` in SSE and SSE2 tests too
It looks cleaner and makes it consistent with other X86 tests.
The huge diffs are mostly indentation changes.
Update Trusty target maintainers
Remove Stephen Crane from the list of Trusty target maintainers and add Andrei Homescu (`@ahomescu)` and Chris Wailes.
Add new_cyclic_in for Rc and Arc
Currently, new_cyclic_in does not exist for Rc and Arc. This is an oversight according to https://github.com/rust-lang/wg-allocators/issues/132.
This PR adds new_cyclic_in for Rc and Arc. The implementation is almost the exact same as new_cyclic with some small differences to make it allocator-specific. new_cyclic's implementation has been replaced with a call to `new_cyclic_in(data_fn, Global)`.
Remaining questions:
* ~~Is requiring Allocator to be Clone OK? According to https://github.com/rust-lang/wg-allocators/issues/88, Allocators should be cheap to clone. I'm just hesitant to add unnecessary constraints, though I don't see an obvious workaround for this function since many called functions in new_cyclic_in expect an owned Allocator. I see Allocator.by_ref() as an option, but that doesn't work on when creating Weak { ptr: init_ptr, alloc: alloc.clone() }, because the type of Weak then becomes Weak<T, &A> which is incompatible.~~ Fixed, thank you `@zakarumych!` This PR no longer requires the allocator to be Clone.
* Currently, new_cyclic_in's documentation is almost entirely copy-pasted from new_cyclic, with minor tweaks to make it more accurate (e.g. Rc<T> -> Rc<T, A>). The example section is removed to mitigate redundancy and instead redirects to cyclic_in. Is this appropriate?
* ~~The comments in new_cyclic_in (and much of the implementation) are also copy-pasted from new_cyclic. Would it be better to make a helper method new_cyclic_in_internal that both functions call, with either Global or the custom allocator? I'm not sure if that's even possible, since the internal method would have to return Arc<T, Global> and I don't know if it's possible to "downcast" that to an Arc<T>. Maybe transmute would work here?~~ Done, thanks `@zakarumych`
* Arc::new_cyclic is #[inline], but Rc::new_cyclic is not. Which is preferred?
* nit: does it matter where in the impl block new_cyclic_in is defined?
In 2021 pat was changed to recognize `|` at the top level, with
pat_param added to retain the old behavior. This means
pat is subject to the same cross-edition behavior as expr will be in
2024.
Co-authored-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
There's a subtle interaction between macros with metavar expressions and the
edition-dependent fragment matching behavior. This test illustrates the current
behavior when using macro-generating-macros across crate boundaries with
different editions.
Co-Authored-By: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Co-Authored-By: Eric Holk <eric@theincredibleholk.org>
Rollup of 9 pull requests
Successful merges:
- #128535 (Format `std::env::consts` docstrings with markdown backticks)
- #128961 (Fix#128930: Print documentation of CLI options missing their arg)
- #129988 (Use `Vec` in `rustc_interface::Config::locale_resources`)
- #130201 (Encode `coroutine_by_move_body_def_id` in crate metadata)
- #130275 (Don't call `extern_crate` when local crate name is the same as a dependency and we have a trait error)
- #130314 (Use the same precedence for all macro-like exprs)
- #130440 (Don't ICE in `opaque_hidden_inferred_bound` lint for RPITIT in trait with no default method body)
- #130458 (`rustc_codegen_ssa` cleanups)
- #130469 (Mark `where_clauses_object_safety` as removed)
r? `@ghost`
`@rustbot` modify labels: rollup
In the implementation of `force_mut`, I chose performance over safety.
For `LazyLock` this isn't really a choice; the code has to be unsafe.
But for `LazyCell`, we can have a full-safe implementation, but it will
be a bit less performant, so I went with the unsafe approach.
Use the same precedence for all macro-like exprs
No need to make these have a different precedence since they're all written like `whatever!(expr)`, and it makes it simpler when adding new macro-based built-in operators in the future.
Don't call `extern_crate` when local crate name is the same as a dependency and we have a trait error
#124944 implemented logic to point out when a trait bound failure involves a *trait* and *type* who come from identically named but different crates. This logic calls the `extern_crate` query which is not valid on `LOCAL_CRATE` cnum, so let's filter that out eagerly.
Fixes#130272Fixes#129184
Encode `coroutine_by_move_body_def_id` in crate metadata
We synthesize the MIR for a by-move body for the `FnOnce` implementation of async closures. It can be accessed with the `coroutine_by_move_body_def_id` query. We weren't encoding this query in the metadata though, nor were we properly recording that synthetic MIR in `mir_keys`, so the `optimized_mir` wasn't getting encoded either!
Stacked on top is a fix to consider `DefKind::SyntheticCoroutineBody` to return true in several places I missed. Specifically, we should consider the def-kind in `fn DefKind::is_fn_like()`, since that's what we were using to make sure we ensure `query mir_inliner_callees` before the MIR gets stolen for the body. This led to some CI failures that were caught by miri but which I added a test for.
Use `Vec` in `rustc_interface::Config::locale_resources`
This allows a third-party tool to injects its own resources, when receiving the config via `rustc_driver::Callbacks::config`.
Fix#128930: Print documentation of CLI options missing their arg
Fix#128930. Failing to give an argument to CLI options which require it now prints something like:
```
$ rustc --print
error: Argument to option 'print' missing
Usage:
--print [crate-name|file-names|sysroot|target-libdir|cfg|check-cfg|calling-conventions|target-list|target-cpus|target-features|relocation-models|code-models|tls-models|target-spec-json|all-target-specs-json|native-static-libs|stack-protector-strategies|link-args|deployment-target]
Compiler information to print on stdout
```
On LLVM 20, these instructions already get eliminated, which at least
partially satisfies a TODO. I'm not talented enough at using FileCheck
to try and constrain this further, but if we really want to we could
copy an LLVM 20 specific version of this test that would restore it to
being CHECK-NEXT: insertvalue ...
@rustbot label: +llvm-main
Relate receiver invariantly in method probe for `Mode::Path`
Effectively reverts part of #126128Fixes#126227
This PR changes method probing to use equality for fully path-based method lookup, and subtyping for receiver `.` method lookup.
r? lcnr
