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

// This was triggering an assertion failure in `NodeRange::new`.

#![feature(cfg_eval)]
#![feature(stmt_expr_attributes)]

fn f() -> u32 {
    #[cfg_eval] #[cfg(not(FALSE))] 0
    //~^ ERROR removing an expression is not supported in this position
}

fn main() {}
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 07:47:53 +00:00			// This was triggering an assertion failure in `NodeRange::new`.

			`#![feature(cfg_eval)]`
			`#![feature(stmt_expr_attributes)]`

			`fn f() -> u32 {`
			`#[cfg_eval] #[cfg(not(FALSE))] 0`
			`//~^ ERROR removing an expression is not supported in this position`
			`}`

			`fn main() {}`