Split Diagnostics for Uncommon Codepoints: Add Individual Identifier Types
This pull request further modifies the `uncommon_codepoints` lint, adding the individual identifier types of `Technical`, `Not_NFKC`, `Exclusion` and `Limited_Use` to the diagnostic message.
Example rendered diagnostic:
```
error: identifier contains a Unicode codepoint that is not used in normalized strings: 'ij'
--> $DIR/lint-uncommon-codepoints.rs:6:4
|
LL | fn dijkstra() {}
| ^^^^^^^
= note: this character is included in the Not_NFKC Unicode general security profile
```
Second step of #120228.
Add allow-by-default lint for unit bindings
### Example
```rust
#![warn(unit_bindings)]
macro_rules! owo {
() => {
let whats_this = ();
}
}
fn main() {
// No warning if user explicitly wrote `()` on either side.
let expr = ();
let () = expr;
let _ = ();
let _ = expr; //~ WARN binding has unit type
let pat = expr; //~ WARN binding has unit type
let _pat = expr; //~ WARN binding has unit type
// No warning for let bindings with unit type in macro expansions.
owo!();
// No warning if user explicitly annotates the unit type on the binding.
let pat: () = expr;
}
```
outputs
```
warning: binding has unit type `()`
--> $DIR/unit-bindings.rs:17:5
|
LL | let _ = expr;
| ^^^^-^^^^^^^^
| |
| this pattern is inferred to be the unit type `()`
|
note: the lint level is defined here
--> $DIR/unit-bindings.rs:3:9
|
LL | #![warn(unit_bindings)]
| ^^^^^^^^^^^^^
warning: binding has unit type `()`
--> $DIR/unit-bindings.rs:18:5
|
LL | let pat = expr;
| ^^^^---^^^^^^^^
| |
| this pattern is inferred to be the unit type `()`
warning: binding has unit type `()`
--> $DIR/unit-bindings.rs:19:5
|
LL | let _pat = expr;
| ^^^^----^^^^^^^^
| |
| this pattern is inferred to be the unit type `()`
warning: 3 warnings emitted
```
This lint is not triggered if any of the following conditions are met:
- The user explicitly annotates the binding with the `()` type.
- The binding is from a macro expansion.
- The user explicitly wrote `let () = init;`
- The user explicitly wrote `let pat = ();`. This is allowed for local lifetimes.
### Known Issue
It is known that this lint can trigger on some proc-macro generated code whose span returns false for `Span::from_expansion` because e.g. the proc-macro simply forwards user code spans, and otherwise don't have distinguishing syntax context compared to non-macro-generated code. For those kind of proc-macros, I believe the correct way to fix them is to instead emit identifers with span like `Span::mixed_site().located_at(user_span)`.
Closes#71432.
This lint is not triggered if any of the following conditions are met:
- The user explicitly annotates the binding with the `()` type.
- The binding is from a macro expansion.
- The user explicitly wrote `let () = init;`
- The user explicitly wrote `let pat = ();`. This is allowed for local
lifetimes.
Clarify `invalid_reference_casting` lint around interior mutable types
This is PR intends to clarify the `invalid_reference_casting` lint around interior mutable types by adding a note for them saying that they should go through `UnsafeCell::get`.
So for this code:
```rust
let cell = &std::cell::UnsafeCell::new(0);
let _num = &mut *(cell as *const _ as *mut i32);
```
the following note will be added to the lint output:
```diff
error: casting `&T` to `&mut T` is undefined behavior, even if the reference is unused, consider instead using an `UnsafeCell`
--> $DIR/reference_casting.rs:68:16
|
LL | let _num = &mut *(cell as *const _ as *mut i32);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit <https://doc.rust-lang.org/book/ch15-05-interior-mutability.html>
+ = note: even for types with interior mutability, the only legal way to obtain a mutable pointer from a shared reference is through `UnsafeCell::get`
```
Suggestion are welcome around the note contents.
Fixes https://github.com/rust-lang/rust/issues/116410
cc `@RalfJung`
We're stabilizing `async fn` in trait (AFIT), but we have some
reservations about how people might use this in the definitions of
publicly-visible traits, so we're going to lint about that.
This is a bit of an odd lint for `rustc`. We normally don't lint just
to have people confirm that they understand how Rust works. But in
this one exceptional case, this seems like the right thing to do as
compared to the other plausible alternatives.
In this commit, we describe the nature of this odd lint.
Make useless_ptr_null_checks smarter about some std functions
This teaches the `useless_ptr_null_checks` lint that some std functions can't ever return null pointers, because they need to point to valid data, get references as input, etc.
This is achieved by introducing an `#[rustc_never_returns_null_ptr]` attribute and adding it to these std functions (gated behind bootstrap `cfg_attr`).
Later on, the attribute could maybe be used to tell LLVM that the returned pointer is never null. I don't expect much impact of that though, as the functions are pretty shallow and usually the input data is already never null.
Follow-up of PR #113657Fixes#114442
