rust/tests/ui/conditional-compilation/invalid-node-range-issue-129166.stderr

error: removing an expression is not supported in this position
  --> $DIR/invalid-node-range-issue-129166.rs:7:17
   |
LL |     #[cfg_eval] #[cfg(not(FALSE))] 0
   |                 ^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error
Return earlier in some cases in `collect_token`. This example triggers an assertion failure: ``` fn f() -> u32 { #[cfg_eval] #[cfg(not(FALSE))] 0 } ``` The sequence of events: - `configure_annotatable` calls `parse_expr_force_collect`, which calls `collect_tokens`. - Within that, we end up in `parse_expr_dot_or_call`, which again calls `collect_tokens`. - The return value of the `f` call is the expression `0`. - This inner call collects tokens for `0` (parser range 10..11) and creates a replacement covering `#[cfg(not(FALSE))] 0` (parser range 0..11). - We return to the outer `collect_tokens` call. The return value of the `f` call is again the expression `0`, again with the range 10..11, but the replacement from earlier covers the range 0..11. The code mistakenly assumes that any attributes from an inner `collect_tokens` call fit entirely within the body of the result of an outer `collect_tokens` call. So it adjusts the replacement parser range 0..11 to a node range by subtracting 10, resulting in -10..1. This is an invalid range and triggers an assertion failure. It's tricky to follow, but basically things get complicated when an AST node is returned from an inner `collect_tokens` call and then returned again from an outer `collect_token` node without being wrapped in any kind of additional layer. This commit changes `collect_tokens` to return early in some extra cases, avoiding the construction of lazy tokens. In the example above, the outer `collect_tokens` returns earlier because the `0` token already has tokens and `self.capture_state.capturing` is `Capturing::No`. This early return avoids the creation of the invalid range and the assertion failure. Fixes #129166. Note: these invalid ranges have been happening for a long time. #128725 looks like it's at fault only because it introduced the assertion that catches the invalid ranges. 2024-08-20 17:47:53 +10:00			`error: removing an expression is not supported in this position`
			`--> $DIR/invalid-node-range-issue-129166.rs:7:17`
			`\|`
			`LL \| #[cfg_eval] #[cfg(not(FALSE))] 0`
			`\| ^^^^^^^^^^^^^^^^^^`

			`error: aborting due to 1 previous error`