6

Add allow-by-default lint for unit bindings by jieyouxu · Pull Request #112380 ·...

 9 months ago
source link: https://github.com/rust-lang/rust/pull/112380
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Contributor

Example

#![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.

mbrubeck, riking, and goffrie reacted with heart emojiJarvisCraft reacted with rocket emoji

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK