Skip to content

Conversation

@mu001999
Copy link
Contributor

@mu001999 mu001999 commented Sep 24, 2025

Fixes #146968

Emit error CfgPredicateIdentifier if the word is path-segment keyword.

Detailed change description - #146978 (comment).

r? petrochenkov

@rustbot
Copy link
Collaborator

rustbot commented Sep 24, 2025

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 24, 2025
@petrochenkov
Copy link
Contributor

Could you

  • add similar test cases for some non path-segment keyword, like struct
  • add test cases for --cfg on command line and make sure that they behave identically to cfg! and #[cfg].

After that we should be able to run crater on this.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 26, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 26, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 505d13f to b2be57d Compare September 27, 2025 03:24
@rustbot

This comment has been minimized.

@mu001999
Copy link
Contributor Author

add test cases for --cfg on command line and make sure that they behave identically to cfg! and #[cfg]

--cfg will emit same error but will be suppressed because parse_cfg is called with ParseSess::with_fatal_emitter

@mu001999
Copy link
Contributor Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 27, 2025
@petrochenkov
Copy link
Contributor

add test cases for --cfg on command line and make sure that they behave identically to cfg! and #[cfg]

--cfg will emit same error but will be suppressed because parse_cfg is called with ParseSess::with_fatal_emitter

with_fatal_emitter doesn't suppress errors, it makes them fatal.
--cfg parsing has its own error reporting logic in fn parse_cfg in compiler\rustc_interface\src\interface.rs, and the new errors are not emitted there.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 30, 2025
@mu001999
Copy link
Contributor Author

with_fatal_emitter doesn't suppress errors, it makes them fatal.

@petrochenkov I found with_fatal_emitter create dcx with FatalOnlyEmitter, see

pub fn with_fatal_emitter(locale_resources: Vec<&'static str>, fatal_note: String) -> Self {
let translator = Translator::with_fallback_bundle(locale_resources, false);
let sm = Arc::new(SourceMap::new(FilePathMapping::empty()));
let fatal_emitter =
Box::new(HumanEmitter::new(stderr_destination(ColorConfig::Auto), translator));
let dcx = DiagCtxt::new(Box::new(FatalOnlyEmitter {
fatal_emitter,
fatal_note: Some(fatal_note),
}))
.disable_warnings();
ParseSess::with_dcx(dcx, sm)
}

and the comment of FatalOnlyEmitter and the impl of FatalOnlyEmitter::emit_diagnostic show only errors with diag.level == Level::Fatal can be emitted, see

/// An emitter that does nothing when emitting a non-fatal diagnostic.
/// Fatal diagnostics are forwarded to `fatal_emitter` to avoid silent
/// failures of rustc, as witnessed e.g. in issue #89358.
pub struct FatalOnlyEmitter {
pub fatal_emitter: Box<dyn Emitter + DynSend>,
pub fatal_note: Option<String>,
}
impl Emitter for FatalOnlyEmitter {
fn source_map(&self) -> Option<&SourceMap> {
None
}
fn emit_diagnostic(&mut self, mut diag: DiagInner, registry: &Registry) {
if diag.level == Level::Fatal {
if let Some(fatal_note) = &self.fatal_note {
diag.sub(Level::Note, fatal_note.clone(), MultiSpan::new());
}
self.fatal_emitter.emit_diagnostic(diag, registry);
}
}
fn translator(&self) -> &Translator {
self.fatal_emitter.translator()
}
}

@mu001999
Copy link
Contributor Author

mu001999 commented Sep 30, 2025

I have debug the logic in fn parse_cfg, and the err.emit is called in fact, but it is suppressed by the FatalOnlyEmitter.

@petrochenkov
Copy link
Contributor

petrochenkov commented Sep 30, 2025

Ah, ok, "fatal emitter" means "fatal-only emitter".

In any case, the behavior is not correct.
I guess the assumption when using the fatal emitter was that we always reach the "expected key or key="value"" error at the bottom anyway, but that's not actually the case.
If we get to return (ident.name, meta_item.value_str()), then all the non-fatal errors are lost, which is incorrect.

@mu001999 mu001999 marked this pull request as draft October 9, 2025 06:02
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 956aa91 to 97cd2c7 Compare October 9, 2025 11:16
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 97cd2c7 to a7d6090 Compare October 9, 2025 11:54
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from a7d6090 to c8bc460 Compare October 9, 2025 15:31
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from cc53ca4 to 9c2ed4c Compare October 9, 2025 18:10
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 21, 2025
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Nov 21, 2025

📌 Commit fc822f8 has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 21, 2025
bors added a commit that referenced this pull request Nov 21, 2025
Rollup of 7 pull requests

Successful merges:

 - #146978 (Emit error when using path-segment keyword as cfg pred)
 - #148719 (Allow unnormalized types in drop elaboration)
 - #148795 (add `rust.rustflags` and per target `rustflags` options to `bootstrap.toml`)
 - #149028 ([rustdoc] Remove `UrlFragment::render` method to unify `clean::types::links` and `anchor`)
 - #149043 ( rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution)
 - #149098 (Fix error message for calling a non-tuple struct)
 - #149151 (Add test for importing path-segment keyword)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 33d11ef into rust-lang:main Nov 21, 2025
11 checks passed
@rustbot rustbot added this to the 1.93.0 milestone Nov 21, 2025
rust-timer added a commit that referenced this pull request Nov 22, 2025
Rollup merge of #146978 - mu001999-contrib:fix/path-kw-as-cfg-pred, r=petrochenkov

Emit error when using path-segment keyword as cfg pred

Fixes #146968

Emit error `CfgPredicateIdentifier` if the word is path-segment keyword.

Detailed change description - #146978 (comment).

r? petrochenkov
@mu001999 mu001999 deleted the fix/path-kw-as-cfg-pred branch November 22, 2025 03:30
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 14, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang#149692.

On beta after rust-lang#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
rust-timer added a commit that referenced this pull request Jan 15, 2026
Rollup merge of #150590 - ident-kw-ice, r=petrochenkov

Don't try to recover keyword as non-keyword identifier

Fixes #149692.

On beta after #146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect #146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jan 15, 2026
Don't try to recover keyword as non-keyword identifier

Fixes rust-lang/rust#149692.

On beta after rust-lang/rust#146978, we ICE on

```rs
macro_rules! m {
    ($id:item()) => {}
}

m!(Self());
```

where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.

I suspect rust-lang/rust#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like

```rs
error: expected identifier, found keyword `Self`
 --> src/lib.rs:5:4
  |
5 | m!(Self());
  |    ^^^^ expected identifier, found keyword

error: missing `fn` or `struct` for function or struct definition
 --> src/lib.rs:5:4
  |
2 |     ($id:item()) => {}
  |      -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
  |    ^^^^
  |
help: if you meant to call a macro, try
  |
5 | m!(Self!());
  |        +
```

I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 19, 2026
Parse ident with allowing recovery when trying to diagnose

Fixes rust-lang#151238

rust-lang#146978 made parsing ident not always allowed-recovery ([change](https://github.com/rust-lang/rust/pull/146978/changes#diff-ef8d6186dc7fb1d03a71446d0c9e6cc9e72158ec6896703dcf05686ee7dc83fcL469-R469)), so when matching macro with `NoopTracker`, which has `Recovery::Forbidden`, ICE happens when trying to parse kw as ident and then unwraping it.

This PR introduces a new method for parsing ident with allowing recovery when trying to diagnose. Then errors will behave like previous.

r? @petrochenkov
rust-timer added a commit that referenced this pull request Jan 20, 2026
Rollup merge of #151249 - fix/151238, r=petrochenkov

Parse ident with allowing recovery when trying to diagnose

Fixes #151238

#146978 made parsing ident not always allowed-recovery ([change](https://github.com/rust-lang/rust/pull/146978/changes#diff-ef8d6186dc7fb1d03a71446d0c9e6cc9e72158ec6896703dcf05686ee7dc83fcL469-R469)), so when matching macro with `NoopTracker`, which has `Recovery::Forbidden`, ICE happens when trying to parse kw as ident and then unwraping it.

This PR introduces a new method for parsing ident with allowing recovery when trying to diagnose. Then errors will behave like previous.

r? @petrochenkov
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jan 20, 2026
Parse ident with allowing recovery when trying to diagnose

Fixes rust-lang/rust#151238

rust-lang/rust#146978 made parsing ident not always allowed-recovery ([change](https://github.com/rust-lang/rust/pull/146978/changes#diff-ef8d6186dc7fb1d03a71446d0c9e6cc9e72158ec6896703dcf05686ee7dc83fcL469-R469)), so when matching macro with `NoopTracker`, which has `Recovery::Forbidden`, ICE happens when trying to parse kw as ident and then unwraping it.

This PR introduces a new method for parsing ident with allowing recovery when trying to diagnose. Then errors will behave like previous.

r? @petrochenkov
github-actions bot pushed a commit to rust-lang/rust-analyzer that referenced this pull request Jan 22, 2026
Parse ident with allowing recovery when trying to diagnose

Fixes rust-lang/rust#151238

rust-lang/rust#146978 made parsing ident not always allowed-recovery ([change](https://github.com/rust-lang/rust/pull/146978/changes#diff-ef8d6186dc7fb1d03a71446d0c9e6cc9e72158ec6896703dcf05686ee7dc83fcL469-R469)), so when matching macro with `NoopTracker`, which has `Recovery::Forbidden`, ICE happens when trying to parse kw as ident and then unwraping it.

This PR introduces a new method for parsing ident with allowing recovery when trying to diagnose. Then errors will behave like previous.

r? @petrochenkov
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Jan 23, 2026
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [rust](https://github.com/rust-lang/rust) | minor | `1.92.0` → `1.93.0` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>rust-lang/rust (rust)</summary>

### [`v1.93.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1930-2026-01-22)

[Compare Source](rust-lang/rust@1.92.0...1.93.0)

\==========================

<a id="1.93.0-Language"></a>

## Language

- [Stabilize several s390x `vector`-related target features and the `is_s390x_feature_detected!` macro](rust-lang/rust#145656)
- [Stabilize declaration of C-style variadic functions for the `system` ABI](rust-lang/rust#145954)
- [Emit error when using some keyword as a `cfg` predicate](rust-lang/rust#146978)
- [Stabilize `asm_cfg`](rust-lang/rust#147736)
- [During const-evaluation, support copying pointers byte-by-byte](rust-lang/rust#148259)
- [LUB coercions now correctly handle function item types, and functions with differing safeties](rust-lang/rust#148602)
- [Allow `const` items that contain mutable references to `static` (which is *very* unsafe, but not *always* UB)](rust-lang/rust#148746)
- [Add warn-by-default `const_item_interior_mutations` lint to warn against calls which mutate interior mutable `const` items](rust-lang/rust#148407)
- [Add warn-by-default `function_casts_as_integer` lint](rust-lang/rust#141470)

<a id="1.93.0-Compiler"></a>

## Compiler

- [Stabilize `-Cjump-tables=bool`](rust-lang/rust#145974). The flag was previously called `-Zno-jump-tables`.

<a id="1.93.0-Platform-Support"></a>

## Platform Support

- [Promote `riscv64a23-unknown-linux-gnu` to Tier 2 (without host tools)](rust-lang/rust#148435)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

[platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html

<a id="1.93.0-Libraries"></a>

## Libraries

- [Stop internally using `specialization` on the `Copy` trait as it is unsound in the presence of lifetime dependent `Copy` implementations. This may result in some performance regressions as some standard library APIs may now call `Clone::clone` instead of performing bitwise copies](rust-lang/rust#135634)
- [Allow the global allocator to use thread-local storage and `std::thread::current()`](rust-lang/rust#144465)
- [Make `BTree::append` not update existing keys when appending an entry which already exists](rust-lang/rust#145628)
- [Don't require `T: RefUnwindSafe` for `vec::IntoIter<T>: UnwindSafe`](rust-lang/rust#145665)

<a id="1.93.0-Stabilized-APIs"></a>

## Stabilized APIs

- [`<[MaybeUninit<T>]>::assume_init_drop`](https://doc.rust-lang.org/stable/core/primitive.slice.html#method.assume_init_drop)
- [`<[MaybeUninit<T>]>::assume_init_ref`](https://doc.rust-lang.org/stable/core/primitive.slice.html#method.assume_init_ref)
- [`<[MaybeUninit<T>]>::assume_init_mut`](https://doc.rust-lang.org/stable/core/primitive.slice.html#method.assume_init_mut)
- [`<[MaybeUninit<T>]>::write_copy_of_slice`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.write_copy_of_slice)
- [`<[MaybeUninit<T>]>::write_clone_of_slice`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.write_clone_of_slice)
- [`String::into_raw_parts`](https://doc.rust-lang.org/stable/std/string/struct.String.html#method.into_raw_parts)
- [`Vec::into_raw_parts`](https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.into_raw_parts)
- [`<iN>::unchecked_neg`](https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_neg)
- [`<iN>::unchecked_shl`](https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_shl)
- [`<iN>::unchecked_shr`](https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_shr)
- [`<uN>::unchecked_shl`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.unchecked_shl)
- [`<uN>::unchecked_shr`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.unchecked_shr)
- [`<[T]>::as_array`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_array)
- [`<[T]>::as_array_mut`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_mut_array)
- [`<*const [T]>::as_array`](https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.as_array)
- [`<*mut [T]>::as_array_mut`](https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.as_mut_array)
- [`VecDeque::pop_front_if`](https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.pop_front_if)
- [`VecDeque::pop_back_if`](https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.pop_back_if)
- [`Duration::from_nanos_u128`](https://doc.rust-lang.org/stable/std/time/struct.Duration.html#method.from_nanos_u128)
- [`char::MAX_LEN_UTF8`](https://doc.rust-lang.org/stable/std/primitive.char.html#associatedconstant.MAX_LEN_UTF8)
- [`char::MAX_LEN_UTF16`](https://doc.rust-lang.org/stable/std/primitive.char.html#associatedconstant.MAX_LEN_UTF16)
- [`std::fmt::from_fn`](https://doc.rust-lang.org/stable/std/fmt/fn.from_fn.html)
- [`std::fmt::FromFn`](https://doc.rust-lang.org/stable/std/fmt/struct.FromFn.html)

<a id="1.93.0-Cargo"></a>

## Cargo

- [Enable CARGO\_CFG\_DEBUG\_ASSERTIONS in build scripts based on profile](rust-lang/cargo#16160)
- [In `cargo tree`, support long forms for `--format` variables](rust-lang/cargo#16204)
- [Add `--workspace` to `cargo clean`](rust-lang/cargo#16263)

<a id="1.93.0-Rustdoc"></a>

## Rustdoc

- [Remove `#![doc(document_private_items)]`](rust-lang/rust#146495)
- [Include attribute and derive macros in search filters for "macros"](rust-lang/rust#148176)
- [Include extern crates in search filters for `import`](rust-lang/rust#148301)
- [Validate usage of crate-level doc attributes](rust-lang/rust#149197).  This means if any of `html_favicon_url`, `html_logo_url`, `html_playground_url`, `issue_tracker_base_url`, or `html_no_source` either has a missing value, an unexpected value, or a value of the wrong type, rustdoc will emit the deny-by-default lint `rustdoc::invalid_doc_attributes`.

<a id="1.93.0-Compatibility-Notes"></a>

## Compatibility Notes

- [Introduce `pin_v2` into the builtin attributes namespace](rust-lang/rust#139751)
- [Update bundled musl to 1.2.5](rust-lang/rust#142682)
- [On Emscripten, the unwinding ABI used when compiling with `panic=unwind` was changed from the JS exception handling ABI to the wasm exception handling ABI.](rust-lang/rust#147224) If linking C/C++ object files with Rust objects, `-fwasm-exceptions` must be passed to the linker now. On nightly Rust, it is possible to get the old behavior with `-Zwasm-emscripten-eh=false -Zbuild-std`, but it will be removed in a future release.
- The `#[test]` attribute, used to define tests, was previously ignored in various places where it had no meaning (e.g on trait methods or types). Putting the `#[test]` attribute in these places is no longer ignored, and will now result in an error; this may also result in errors when generating rustdoc. [Error when `test` attribute is applied to structs](rust-lang/rust#147841)
- Cargo now sets the `CARGO_CFG_DEBUG_ASSERTIONS` environment variable in more situations. This will cause crates depending on `static-init` versions 1.0.1 to 1.0.3 to fail compilation with "failed to resolve: use of unresolved module or unlinked crate `parking_lot`". See [the linked issue](rust-lang/rust#150646 (comment)) for details.
- [User written types in the `offset_of!` macro are now checked to be well formed.](rust-lang/rust#150465)
- `cargo publish` no longer emits `.crate` files as a final artifact for user access when the `build.build-dir` config is unset
- [Upgrade the `deref_nullptr` lint from warn-by-default to deny-by-default](rust-lang/rust#148122)
- [Add future-incompatibility warning for `...` function parameters without a pattern outside of `extern` blocks](rust-lang/rust#143619)
- [Introduce future-compatibility warning for `repr(C)` enums whose discriminant values do not fit into a `c_int` or `c_uint`](rust-lang/rust#147017)
- [Introduce future-compatibility warning against ignoring `repr(C)` types as part of `repr(transparent)`](rust-lang/rust#147185)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi44OC4yIiwidXBkYXRlZEluVmVyIjoiNDIuODguMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90IiwiYXV0b21hdGlvbjpib3QtYXV0aG9yZWQiLCJkZXBlbmRlbmN5LXR5cGU6Om1pbm9yIl19-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-explicit_tail_calls `#![feature(explicit_tail_calls)]` finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team to-announce Announce this issue on triage meeting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cfg!($crate), cfg!(crate), cfg!(self), cfg!(Self), and cfg!(super) should not be accepted