Rustup #15531
Merged
Rustup #15531
+430
−305
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`rustc` 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<Output = bool>`
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.
Tweak invalid builtin attribute output - Add link to reference/docs when possible - More accurate suggestions by supporting multiple alternative suggestions ``` error: malformed `crate_type` attribute input --> $DIR/crate-type-macro-call.rs:1:1 | LL | #![crate_type = foo!()] | ^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, visit <https://doc.rust-lang.org/reference/linkage.html> help: the following are the possible correct uses | LL - #![crate_type = foo!()] LL + #![crate_type = "bin"] | LL - #![crate_type = foo!()] LL + #![crate_type = "cdylib"] | LL - #![crate_type = foo!()] LL + #![crate_type = "dylib"] | LL - #![crate_type = foo!()] LL + #![crate_type = "lib"] | = and 4 other candidates ```
Account for new `assert!` desugaring in `!condition` suggestion `rustc` in rust-lang/rust#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<Output = bool>` 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 rust-lang#15453 to the rustc repo. r? `````@samueltardieu`````
Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect at all. (And if it did, whether that effect is still achieved today.)
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.
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.
In the desugaring of `assert!`, we now expand to a `match` expression
instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not
the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
`assert!(val)` now desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix #122159.
We make some minor changes to some diagnostics to avoid span overlap on
type mismatch or inverted "expected"/"found" on type errors.
We remove some unnecessary parens from core, alloc and miri.
address review comments
Stabilize `path_file_prefix` feature This stabilises `Path::file_prefix`, following the FCP in [tracking issue ](rust-lang/rust#86319) (FCP ended almost a year ago, so if it's needed for proccess we could rerun it) Closes: rust-lang/rust#86319
…nkov 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````````
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 rust-lang/rust#144131 splits module scope into two scopes for globs and non-globs, but simpler.
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix #122159.
Revert "Partially outline code inside the panic! macro". This reverts rust-lang/rust#115670 Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`. This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
Prevent impossible combinations in `ast::ModKind`. `ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`. This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`. r? ```@Urgau```
|
rustbot has assigned @samueltardieu. Use |
rustbot
added
the
S-waiting-on-review
|
flip1995
commented
Aug 22, 2025
Comment on lines
+47
to
+48
| // FIXME: reintroduce a better check after this is merged back into Clippy | ||
| if is_in_const_context(cx) { |
There was a problem hiding this comment.
IIRC there's already an issue for this? 🤔
There was a problem hiding this comment.
Yes, I'll take care of submitting the PR after testing the fix again.
flip1995
commented
Aug 22, 2025
| (_, HasSafetyComment::Yes(pos)) => { | ||
| if !is_lint_allowed(cx, UNNECESSARY_SAFETY_COMMENT, item.hir_id()) { | ||
| let (span, help_span) = mk_spans(pos); | ||
| match item_has_safety_comment { |
There was a problem hiding this comment.
This one I reworked, as the function got too long 105/100 LoC
flip1995
commented
Aug 22, 2025
Comment on lines
+75
to
+77
| [lints.rust.unexpected_cfgs] | ||
| level = "warn" | ||
| check-cfg = ['cfg(bootstrap)'] |
There was a problem hiding this comment.
Copied from miri. This is now necessary, as Clippy is now build as a stage1 tool in the Rust repo.
|
Lintcheck changes for 60374e2
This comment will be updated if you push new changes |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Letting rustbot assign a reviewer, so that someone can double check 9de86f4.
changelog: none