rust/src/tools, branch lcnr/rustc-dev-guide

Auto merge of #144793 - petrochenkov:extprel3, r=davidtwco

2025-08-13T22:52:17+00:00

resolve: Split extern prelude into two scopes One scope for `extern crate` items and another for `--extern` options, with the former shadowing the latter. If in a single scope some things can overwrite other things, especially with ad hoc restrictions like `MacroExpandedExternCrateCannotShadowExternArguments`, then it's not really a single scope. So this PR splits `Scope::ExternPrelude` into two cleaner scopes. This is similar to how https://github.com/rust-lang/rust/pull/144131 splits module scope into two scopes for globs and non-globs, but simpler.

Rollup merge of #145153 - joshtriplett:macro-kinds-plural, r=petrochenkov

2025-08-13T16:43:01+00:00

Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ````````@petrochenkov````````

Update clippy tests

2025-08-13T16:29:53+00:00

Auto merge of #144722 - ywxt:parallel-reproducibile, r=SparrowLii

2025-08-13T10:39:15+00:00

Fix parallel rustc not being reproducible due to unstable sorts of items Currently, A tuple `(DefId, SymbolName)` is used to determine the order of items in the final binary. However `DefId` is expected as non-deterministic, which leads to some not reproducible issues under parallel compilation. (See https://github.com/rust-lang/rust/issues/140425#issuecomment-3111802148) Theoretically, we don't need the sorting because the order of these items is already deterministic. However, codegen tests reply on the same order of items between in binary and source. So here we added a new option `codegen-source-order` to indicate whether sorting based on the order in source. For codegen tests, items are sorted according to the order in the source code, whereas in the normal path, no sorting is performed. Specially, for codegen tests, in preparation for parallel compilation potentially being enabled by default in the future, we use `Span` replacing `DefId` to make the order deterministic. This PR is purposed to fix rust-lang/rust#140425, but seemly works on rust-lang/rust#140413 too. This behavior hasn't added into any test until we have a test suit for the parallel frontend. (See https://github.com/rust-lang/rust/pull/143953) Related discussion: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Async.20closures.20not.20reproducible.28.23140425.29) https://github.com/rust-lang/rust/pull/144576 Update rust-lang/rust#113349 r? `@oli-obk` cc `@lqd` `@cramertj` `@matthiaskrgr` `@Zoxc` `@SparrowLii` `@bjorn3` `@cjgillot` `@joshtriplett`

Rollup merge of #144870 - Kivooeo:file_prefix-stabilize, r=tgross35

2025-08-13T05:03:47+00:00

Stabilize `path_file_prefix` feature This stabilises `Path::file_prefix`, following the FCP in [tracking issue ](https://github.com/rust-lang/rust/issues/86319) (FCP ended almost a year ago, so if it's needed for proccess we could rerun it) Closes: https://github.com/rust-lang/rust/issues/86319

Fix pgo tests

2025-08-13T01:42:46+00:00

Fix parallel rustc not being reproducible due to unstable sorting of items.

2025-08-13T00:59:32+00:00

clippy: Update for switch to `MacroKinds`

2025-08-12T16:24:45+00:00

This updates two clippy lints which had exceptions for `MacroKind::Bang` macros to extend those exceptions to any macro, now that a macro_rules macro can be any kind of macro.

Auto merge of #144678 - jdonszelmann:no-mangle-extern, r=bjorn3

2025-08-12T16:20:24+00:00

Make no_mangle on foreign items explicit instead of implicit for a followup PR I'm working on I need some foreign items to mangle. I could add a new attribute: `no_no_mangle` or something silly like that but by explicitly putting `no_mangle` in the codegen fn attrs of foreign items we can default it to `no_mangle` and then easily remove it when we don't want it. I guess you'd know about this r? `@bjorn3.` Shouldn't be too hard to review :) Builds on rust-lang/rust#144655 which should merge first.

Rollup merge of #145273 - estebank:not-not, r=samueltardieu

2025-08-12T10:37:57+00:00

Account for new `assert!` desugaring in `!condition` suggestion `rustc` in https://github.com/rust-lang/rust/pull/122661 is going to change the desugaring of `assert!` to be ```rust match condition { true => {} _ => panic!(), } ``` which will make the edge-case of `condition` being `impl Not` while not being `bool` itself no longer a straightforward suggestion, but `!!condition` will coerce the expression to be `bool`, so it can be machine applicable. Transposing https://github.com/rust-lang/rust-clippy/pull/15453/ to the rustc repo. r? `````@samueltardieu`````