Fix E0518: invalid label

By Alex Chen
Rust intermediate linux macos windows rust-embedded

Fix E0518: invalid label

Rust’s E0518 error is emitted when you place a label on a construct that cannot legally carry a label. In Rust, labels ('label_name) are only valid on loop and block expressions—nowhere else. Attaching a label to an if expression, match arm, or function call triggers this error.

1. Symptoms

You will see the error manifest in one of two ways during compilation:

Primary error message:

error[E0518]: invalid label –> src/main.rs:5:5 | 5 | ‘block: { break ‘block; }; | ^^^^^^ | = note: labels on blocks are only allowed in break with a value


**Alternative presentation (label placed on non-block/non-loop):**

error[E0518]: invalid label –> src/main.rs:6:9 | 6 | ‘if_label: if true { 42 } else { 0 }; | ^^^^^^^^ | = note: labels are only permitted on blocks and loop constructs


Common code patterns triggering E0518:

```rust
// Pattern 1: Label on an if expression
fn demo1() {
    'label: if condition {  // E0518
        println!("branch");
    }
}

// Pattern 2: Label on a match expression  
fn demo2() -> i32 {
    'label: match Some(10) {  // E0518
        Some(x) => x,
        None => 0,
    }
}

// Pattern 3: Label on a function call
fn demo3() {
    'label: my_function();  // E0518
}

// Pattern 4: Misplaced label on block used as expression
fn demo4() -> i32 {
    return 'label: {  // E0518 — label on return value block
        42
    };
}

2. Root Cause

The root cause is a misunderstanding of where labels are legal in Rust’s syntax. Rust labels follow this grammar:

label := "'" identifier
labeled_expr := label block_expr
             | label loop_expr

Labels are only valid on:

  1. Block expressions ({ ... }) — enables break 'label to return a value from the block.
  2. Loop expressions (loop, while, for) — enables break 'label or continue 'label.

Labels are NOT valid on:

  • if / else expressions
  • match arms and expressions
  • Function calls
  • Field access (expr.field)
  • Binary expressions
  • Return statements (labels go on the block, not the return)
  • Method calls (expr.method())

The error message “invalid label” appears because the Rust parser recognizes the label syntax ('name) but then determines the surrounding construct cannot accept it. The compiler enforces this because labeled break is a control flow mechanism tied to specific constructs.

┌─────────────────────────────────────────────────────┐
│                    VALID LABELS                      │
├─────────────────────────────────────────────────────┤
│                                                     │
│  'outer: loop {          // labeled loop           │
│      'inner: loop {      // nested labeled loop    │
│          continue 'outer;                          │
│          break 'inner;                              │
│      }                                              │
│  }                                                  │
│                                                     │
│  let val = 'block: {       // labeled block         │
│      break 'block 42;     // break with value      │
│  };                                                 │
│                                                     │
└─────────────────────────────────────────────────────┘

          ┌─────────────────────────────────┐
          │       INVALID PLACEMENT         │
          ├─────────────────────────────────┤
          │                                 │
          │  'bad: if condition { ... }     │
          │  'bad: match x { ... }          │
          │  'bad: some_fn()                │
          │  return 'bad: ...               │
          │                                 │
          └─────────────────────────────────┘

3. Step-by-Step Fix

Step 1: Identify the labeled construct

Find every occurrence of 'identifier: in your code and check what follows the colon.

'outer: loop {
    // valid — loop can be labeled
}

Step 2: Determine whether you need a label at all

If you only have one loop or block, you typically do not need a label. Remove the label unless you are dealing with nested loops.

Before:

fn single_loop_no_label_needed() -> i32 {
    let mut count = 0;
    'counter: loop {  // E0518 — only one loop, no label needed
        count += 1;
        if count >= 10 {
            break;
        }
    }
    count
}

After:

fn single_loop_no_label_needed() -> i32 {
    let mut count = 0;
    loop {  // No label — clean and simple
        count += 1;
        if count >= 10 {
            break;
        }
    }
    count
}

Step 3: If using labeled blocks for early return, use a plain block

Labeled blocks exist specifically so that break 'label value can return a value from a block expression. If you don’t need to return a value, use a plain block.

Before:

fn using_labeled_block_wrongly() {
    'block: {
        // No break with value, so label is unnecessary
        println!("inside block");
        break 'block;  // This breaks from the block but label adds nothing
    }
}

After:

fn using_labeled_block_correctly() {
    {
        // Plain block — simpler and clearer
        println!("inside block");
    }
}

Step 4: Use labeled blocks only when breaking with a value from a loop

Labeled blocks are most useful in loop expressions where you need to return a value from an infinite loop.

Before:

fn find_element_in_loop() -> Option<usize> {
    let data = vec![1, 2, 3, 4, 5];
    
    'outer: loop {  // E0518 — label on loop is valid, but not useful here
        for (i, v) in data.iter().enumerate() {
            if *v == 3 {
                break 'outer;  // breaks outer loop
            }
        }
        break;  // falls through to implicit return None
    }
}

After:

fn find_element_in_loop() -> Option<usize> {
    let data = vec![1, 2, 3, 4, 5];
    
    let result = 'block: {  // labeled block to capture a value
        for (i, v) in data.iter().enumerate() {
            if *v == 3 {
                break 'block Some(i);  // return value from block
            }
        }
        break 'block None;  // explicit return if not found
    };
    result
}

Step 5: Use labeled loops for nested break/continue scenarios

Before:

fn nested_loop_label_on_if() -> i32 {
    let mut outer_count = 0;
    let mut inner_count = 0;
    
    'outer: loop {
        'inner: loop {  // valid labels on loops
            inner_count += 1;
            if inner_count >= 3 {
                'bad_label: if true {  // E0518 — label on if
                    break 'outer;
                }
            }
        }
        outer_count += 1;
        if outer_count >= 2 {
            break;
        }
    }
    inner_count
}

After:

fn nested_loop_broken_correctly() -> i32 {
    let mut outer_count = 0;
    let mut inner_count = 0;
    
    'outer: loop {
        'inner: loop {
            inner_count += 1;
            if inner_count >= 3 {
                // Use plain if — no label needed
                if true {
                    break 'outer;
                }
            }
        }
        outer_count += 1;
        if outer_count >= 2 {
            break;
        }
    }
    inner_count
}

Step 6: Replace labeled return expressions with plain return

Before:

fn labeled_return() -> i32 {
    return 'label: {  // E0518 — label on return value expression
        42
    };
}

After:

fn plain_return() -> i32 {
    return {  // Plain block — valid
        42
    };
}

4. Verification

After applying the fix, recompile your code. A clean build confirms resolution:

$ cargo build
   Compiling my_project v0.1.0 (file:///projects/my_project)
    Finished dev [unoptimized + debuginfo] target(s) in 0.32s

For labeled blocks returning values, verify the logic with a test:

#[test]
fn test_find_element() {
    let result = 'block: {
        let data = vec![10, 20, 30];
        for (i, v) in data.iter().enumerate() {
            if *v == 20 {
                break 'block Some(i);
            }
        }
        break 'block None;
    };
    
    assert_eq!(result, Some(1));
}

#[test]
fn test_not_found() {
    let result = 'block: {
        let data = vec![10, 20, 30];
        for (i, v) in data.iter().enumerate() {
            if *v == 99 {
                break 'block Some(i);
            }
        }
        break 'block None;
    };
    
    assert_eq!(result, None);
}

Run the tests:

$ cargo test
   Compiling my_project v0.1.0 (file:///projects/my_project)
    Finished dev [unoptimized + debuginfo] target(s) in 0.42s
     Running unittests src/lib.rs (target/debug/deps/my_project-...)
running 2 tests
test test_find_element ... ok
test test_find_element_not_found ... ok
test result: ok. passed 2

5. Common Pitfalls

Pitfall 1: Thinking break 'label works with if blocks

Labels on if expressions are syntactically invalid. You cannot write break 'label from within an if body unless the if itself lives inside a labeled loop or block. The break target must be the enclosing loop or block, not the if.

Pitfall 2: Mixing labeled blocks with return

// WRONG — E0518
fn example() -> i32 {
    return 'block: { 42 };
}

// CORRECT
fn example() -> i32 {
    return { 42 };  // or just: return 42;
}

The label belongs on the block expression, not on the return keyword. However, if the block is just return’s expression, a label is unnecessary.

Pitfall 3: Assuming labels can be used for early continue from blocks

continue only works with loops. You cannot write continue 'block from a labeled block. Use break 'block instead.

// WRONG — E0518 or E0424 depending on context
fn bad() {
    'block: {
        continue 'block;  // E0518: continue cannot target a block
    }
}

// CORRECT — use break to skip the rest of the block
fn good() {
    'block: {
        let should_skip = true;
        if should_skip {
            break 'block;  // exits the block
        }
        println!("this is skipped");
    }
}

Pitfall 4: Nested labeled blocks with implicit fall-through

When using labeled blocks, every code path must either break 'block value or reach the end. Reaching the end of a labeled block without an explicit break is a compile error in Rust:

// WRONG — E0429: block in break expression must have a value
fn bad() -> i32 {
    'block: {
        if true {
            break 'block 1;
        }
        // Error: missing break 'block at end of block
    }
}

// CORRECT
fn good() -> i32 {
    'block: {
        if true {
            break 'block 1;
        }
        break 'block 0;  // explicit fallback
    }
}

Pitfall 5: Label shadows

Using the same label name in nested scopes can cause confusion and is flagged by the compiler:

fn shadowing() {
    'label: loop {
        'label: loop {  // warning: label 'label shadows a label of the same name
            break 'label;  // refers to inner loop
        }
        break 'label;  // refers to outer loop
    }
}
Error Code Description
E0261 Use of moved value (when label usage moves values unexpectedly)
E0262 Declaring internal item in trait or impl
E0270 Block returns a value when it should not (in break context)
E0690 Invalid block return type (mismatched type in labeled block)
E0424 continue cannot be used in labeled block

Contrast with E0424: E0424 occurs when you try continue 'label where the label points to a block rather than a loop. E0518 occurs earlier—during parsing—when the label itself is syntactically placed on a construct that cannot accept labels.

Contrast with E0270: E0270 is about the block not returning a value when break 'block value is used. E0518 is about the label placement being structurally invalid. They can appear together if you both misplace the label and provide an invalid value.

// E0518 + E0270 possible
fn both_errors() -> i32 {
    'bad: {  // E0518: block labeled, but then...
        break 'bad "text";  // E0270: wrong type
    }
}

The fix strategy is always the same: identify where the label sits, determine if a label is necessary, and either remove it or attach it only to loops and blocks.

rust e0518 label break continue compiler-error