rust/tests/incremental/issue-85197-invalid-span/auxiliary/invalid-span-helper-lib.rs

//@ proc-macro: respan.rs
//@ revisions: rpass1 rpass2

extern crate respan;

#[macro_use]
#[path = "invalid-span-helper-mod.rs"]
mod invalid_span_helper_mod;

// Invoke a macro from a different file - this
// allows us to get tokens with spans from different files
helper!(1);
Update tests to use new proc-macro header 2024-11-24 17:37:25 -08:00			`//@ proc-macro: respan.rs`
[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives 2024-02-22 12:10:29 +00:00			`//@ revisions: rpass1 rpass2`
Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes #85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache, but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache, we will decode it with a 'dummy' location, but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`), the metadata encoder would treat it as a normal span, encoding the `SyntaxContext`. As a result, the final span encoded to the metadata would change across sessions, even if the crate itself was unchanged. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext`, and encode location information for spans with a non-dummy location. 2021-05-12 00:10:41 -04:00
			`extern crate respan;`

			`#[macro_use]`
			`#[path = "invalid-span-helper-mod.rs"]`
			`mod invalid_span_helper_mod;`

			`// Invoke a macro from a different file - this`
			`// allows us to get tokens with spans from different files`
			`helper!(1);`