https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=lcnr/rustc-dev-guide 2025-08-13T22:52:17+00:00 2025-08-13T22:52:17+00:00 bors bors@rust-lang.org 2025-08-13T22:52:17+00:00 urn:sha1:8e7795415acaa9471b5eeb2301915d6996d289ec 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. 2025-08-13T16:43:01+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-08-13T16:43:01+00:00 urn:sha1:bd6fb635965cbbc8c70f5e011b5c19711e52a5fe 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```````` 2025-08-13T14:45:40+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2025-08-13T12:46:11+00:00 urn:sha1:d98eaad5096a516f9a1601c61e7e9b6e9f25e695 2025-08-13T14:45:40+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2025-08-01T15:07:59+00:00 urn:sha1:772493d51d24dabbffdc54aaf48859eec85d544e One for `--extern` options and another for `extern crate` items. 2025-08-12T16:24:45+00:00 Josh Triplett josh@joshtriplett.org 2025-08-09T05:49:57+00:00 urn:sha1:ba231db3f33381f417a94566f043738dcaf60fc3 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. Expand test coverage to include all of these cases. 2025-08-12T16:24:45+00:00 Josh Triplett josh@joshtriplett.org 2025-08-09T04:36:17+00:00 urn:sha1:c81fcaca1c4f2e9b39fc8bc3d03a3f19b475d366 2025-08-12T16:24:45+00:00 Josh Triplett josh@joshtriplett.org 2025-08-08T02:21:16+00:00 urn:sha1:0b855bcdc9b0fafa5a4a4330e10655105daf27cb 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. 2025-08-11T22:05:36+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-07-22T01:05:16+00:00 urn:sha1:5bc23ce25548d7f4a9f6ceaa48cc3d8fe7629f58 2025-08-10T19:15:20+00:00 Esteban Küber esteban@kuber.com.ar 2025-06-27T22:38:29+00:00 urn:sha1:29d26f27a6d6c466ed143bdfa128f76a19226743 2025-08-10T19:15:18+00:00 Esteban Küber esteban@kuber.com.ar 2025-01-21T21:07:20+00:00 urn:sha1:464a6b1b4af28f7b2d1adf051bad3f182e23b88e When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value. ``` error[E0603]: struct `Priv1` is private --> $DIR/non-exhaustive-ctor.rs:25:39 | LL | let _ = S { field: (), field1: m::Priv1 {} }; | ------ ^^^^^ private struct | | | while setting this field | note: the struct `Priv1` is defined here --> $DIR/non-exhaustive-ctor.rs:14:4 | LL | struct Priv1 {} | ^^^^^^^^^^^^ help: the field `field1` you're trying to set has a default value, you can use `..` to use it | LL | let _ = S { field: (), .. }; | ~~ ```