bootstrap: Don't pass an unused `--color` to compiletest
- Follow-up to https://github.com/rust-lang/rust/pull/149850
---
This flag was an artifact of compiletest's old libtest-based test executor, and currently doesn't influence compiletest's output at all.
A follow-up commit also inlines `force_coloring_in_ci` into its only remaining caller, and updates its comment.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#142380 (Put negative implementors first and apply same ordering logic to foreign implementors)
- rust-lang/rust#146584 (remove duplicated columns from `rustc_error_code::error_codes!`)
- rust-lang/rust#148717 (Point at span within local macros even when error happens in nested external macro)
- rust-lang/rust#149565 (rustdoc: Add unstable `--merge-doctests=yes/no/auto` flag)
- rust-lang/rust#149770 (Rename some issue-* tests)
- rust-lang/rust#149807 (Use ubuntu:24.04 for the `x86_64-gnu-miri` job)
- rust-lang/rust#149850 (Remove "tidy" tool for `tests/rustdoc` testsuite)
- rust-lang/rust#149863 (Do not suggest moving expression out of for loop when hitting `break` from desugaring)
- rust-lang/rust#149867 (only resolve main in bin crates)
r? `@ghost`
`@rustbot` modify labels: rollup
Point at span within local macros even when error happens in nested external macro
Address issue noticed at https://users.rust-lang.org/t/error-message-does-not-specify-where-in-macro/135157/1. On errors occurring within a macro expansion, point at the innermost local macro expansion point.
```
error[E0308]: mismatched types
--> $DIR/macro-span-caller-replacement.rs:5:17
|
LL | s = format!("{arg}");
| ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL | macro_with_format!();
| -------------------- in this macro invocation
|
= note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)
```
remove duplicated columns from `rustc_error_code::error_codes!`
Possible because of rust-lang/rust#146308 ~~, but currently still blocked on the next stage0 bump~~.
Port `doc` attributes to new attribute API
Part of https://github.com/rust-lang/rust/issues/131229.
This PR ports the `doc` attributes to the new attribute API. However, there are things that will need to be fixed in a follow-up:
* Some part of `cfg_old.rs` are likely unused now, so they should be removed.
* Not all error/lints are emitted at the same time anymore, making them kinda less useful considering that you need to run and fix rustc/rustdoc multiple times to get through all of them.
* For coherency with the other attribute errors, I didn't modify the default output too much, meaning that we have some new messages now. I'll likely come back to that to check if the previous ones were better in a case-by-case approach.
* `doc(test(attr(...)))` is handled in a horrifying manner currently. Until we can handle it correctly with the `Attribute` system, it'll remain that thing we're all very ashamed of. 😈
* A type in rustdoc got its size increased, I'll check the impact on performance. But in any case, I plan to improve it in a follow-up so should be "ok".
* Because of error reporting, some fields of `Doc` are suboptimal, like `inline` which instead of being an `Option` is a `ThinVec` because we report the error later on. Part of the things I'm not super happy about but can be postponed to future me.
* In `src/librustdoc/clean/cfg.rs`, the `pub(crate) fn parse(cfg: &MetaItemInner) -> Result<Cfg, InvalidCfgError> {` function should be removed once `cfg_trace` has been ported to new `cfg` API.
* Size of type `DocFragment` went from 32 to 48. Would be nice to get it back to 32.
* ``malformed `doc` attribute input`` wasn't meant for so many candidates, should be improved.
* See how many of the checks in `check_attr` we can move to attribute parsing
* Port target checking to be in the attribute parser completely
* Fix target checking for `doc(alias)` on fields & patterns
And finally, once this PR is merged, I plan to finally stabilize `doc_cfg` feature. :)
cc `@jdonszelmann`
r? `@JonathanBrouwer`
```
error[E0308]: mismatched types
--> $DIR/macro-span-caller-replacement.rs:5:17
|
LL | s = format!("{arg}");
| ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL | macro_with_format!();
| -------------------- in this macro invocation
|
= note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Build auxiliary in pretty tests
I've encountered a problem with building auxiliary in pretty tests with the following configuration:
```
//@ edition:2021
//@ aux-crate:to_reuse_functions=to-reuse-functions.rs
//@ pretty-mode:hir
//@ pretty-compare-only
//@ pp-exact:delegation-inherit-attributes.pp
```
In such kind of tests, I want to test the resulting HIR, without final typecheck (`pretty-compare-only`). I plan to use such tests during testing the attribute inheritance in delegation feature. However, related auxiliary is built only in [self.typecheck_source](2e667b0c64/src/tools/compiletest/src/runtest/pretty.rs (L79)) method (in `compose_and_run_compiler` routine), so it is impossible to execute test in my scenario. As a solution I've added the auxiliary build in [print_source](2e667b0c64/src/tools/compiletest/src/runtest.rs (L434)) method, so it is also built in a compare only scenarios.
I've tried to search other solutions to this problem, but I haven't found a way to force auxiliary build in such a configuration of a pretty test.
r? `@petrochenkov`
Make `--print=backend-has-zstd` work by default on any backend
Using a defaulted `CodegenBackend` method that querying for zstd support should automatically print a safe value of `false` on any backend that doesn't specifically indicate the presence or absence of zstd.
This should fix the compiletest failures reported in https://github.com/rust-lang/rust/pull/149666#discussion_r2597881482, which can occur when LLVM is not the default codegen backend.
Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type
Point at return type of `async fn`s instead of their def `Span`.
Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type.
Correctly address `type Alias = dyn Trait` when `fn foo() -> Alias { .. }`.
Fixrust-lang/rust#147894.
Remove -Zoom=panic
There are major questions remaining about the reentrancy that this allows. It doesn't have any users on github outside of a single project that uses it in a panic=abort project to show backtraces. It can still be emulated through `#[alloc_error_handler]` or `set_alloc_error_hook` depending on if you use the standard library or not. And finally it makes it harder to do various improvements to the allocator shim.
With this PR the sole remaining symbol in the allocator shim that is not effectively emulating weak symbols is the symbol that prevents skipping the allocator shim on stable even when it would otherwise be empty because libstd + `#[global_allocator]` is used.
Closes https://github.com/rust-lang/rust/issues/43596
Fixes https://github.com/rust-lang/rust/issues/126683
```
error[E0277]: the size for values of type `(dyn Debug + 'static)` cannot be known at compilation time
--> $DIR/dyn-trait-type-alias-return-type.rs:4:11
|
LL | fn f() -> T { loop {} }
| ^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `(dyn Debug + 'static)`
note: this type alias is unsized
--> $DIR/dyn-trait-type-alias-return-type.rs:1:1
|
LL | type T = dyn core::fmt::Debug;
| ^^^^^^
= note: the return type of a function must have a statically known size
```
Retire `opt_str2` from compiletest cli parsing
We have `Option<..>`, we don't need to invent "(none)" as option-at-home.
- More specifically, when some test suite expect certain values to be present, they should `.expect(..)` the value, and not potentially receive some "(none)" in some cases.
r? Zalathar
Using a defaulted `CodegenBackend` method that querying for zstd support should
automatically print a safe value of `false` on any backend that doesn't
specifically indicate the presence or absence of zstd.
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and adding actual support for `-Cdebuginfo=line-tables-only` rather than treating it the same as `-Cdebuginfo=full`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Move ambient gdb discovery from compiletest to bootstrap
- Follow-up to https://github.com/rust-lang/rust/pull/148099
---
This code takes the compiletest code for discovering an “ambient” `gdb` in the user's path, and moves it to bootstrap.
One of the eventual goals is to allow compiletest to assume that if it has been asked to run the debuginfo-gdb suite, then it *must* have been passed an explicit `--gdb`, though we aren't quite there yet.
r? jieyouxu
Tidying up tests/ui/issues tests [3/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
r? Kivooeo
Add warn-by-default lint for visibility on `const _` declarations
Add a warn-by-default `unused_visibilities` lint for visibility qualifiers on `const _` declarations—e.g. `pub const _: () = ();`. Such qualifiers have no effect.
A [Sourcegraph search](https://sourcegraph.com/search?q=context:global+lang:Rust+pub%5Cs*%28%5C%28.*%5C%29%29%3F%5Cs*const%5Cs%2B_%5Cs*:&patternType=regexp&case=yes&sm=0) suggests that this pattern is relatively rare, and mostly found in tests (with only 3 exceptions). So perhaps this could become an FCW/hard error in the future.
`@rustbot` label T-lang A-lints A-visibility -T-clippy
