diff options
| author | bors <bors@rust-lang.org> | 2023-08-12 15:14:42 +0000 | 
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-08-12 15:14:42 +0000 | 
| commit | 1e836d12d39ea09b1d86ebda70cb11b41564cead (patch) | |
| tree | 7e9244701ffa078029e67d7412f7fbe6befda890 /compiler/rustc_incremental | |
| parent | f1b854818db00bec14accbc9d1c72e6ebefe64db (diff) | |
| parent | d801a2ff1565c96d016c4ac783f2d83b967d8ae7 (diff) | |
| download | rust-1e836d12d39ea09b1d86ebda70cb11b41564cead.tar.gz rust-1e836d12d39ea09b1d86ebda70cb11b41564cead.zip  | |
Auto merge of #114710 - Urgau:fix-expect-dead_code-114557, r=cjgillot
Respect `#[expect]` the same way `#[allow]` is with the `dead_code` lint This PR makes the `#[expect]` attribute being respected in the same way the `#[allow]` attribute is with the `dead_code` lint. The fix is much more involved than I would have liked (and it's not because I didn't tried!), because the implementation took advantage of the fact that firing a lint in a allow context is a nop (for the user, as the lint is suppressed) to not fire-it at all. And will it's fine for `#[allow]`, it definitively isn't for `#[expect]`, as the presence and absence of the lint is significant. So a big part of the PR is just adding the context information of whenever an item is on the worklist because of an `[allow]`/`#[expect]` or not. Fixes https://github.com/rust-lang/rust/issues/114557
Diffstat (limited to 'compiler/rustc_incremental')
0 files changed, 0 insertions, 0 deletions
