As an update to my approach described above, the API improvements in https://github.com/rust-lang/rust/pull/40939 got me painfully close to a working prototype but it’s not quite there.
This is because the implementation of the built-in line!() and file!() macros deliberately finds the span of the outermost macro invocation instead of giving the actual source of the invocation, which is, in general, more useful, but causes issues here because they always point to the #[rewrite_unwraps] attribute.
Essentially, I’d like to be able to extract the true file, starting line/column and ending line/column of a given Span, maybe something like this:
impl Span {
/// Get the file into which this span points.
fn file(&self) -> &str {...} // or an interned string type, could be `Term` but
// that's described as a valid identifier which paths usually are not
/// Get the starting line and column of this span in the source file.
fn start(&self) -> (u32, u32) {...}
/// Get the ending line and column of this span in the source file.
fn end(&self) -> (u32, u32) {...}
/// If this span and `other` are adjacent [or overlapping?], return a new span representing the two of them combined.
fn glue(&self, other: Span) -> Option<Span> {...} // This operation is already implemented in libsyntax
}
glue() would also be immensely useful to create a wider, but still valid, span of some non-delimited tokens (like the entire span of a function/method call, which includes two or more separate TokenTree elements). N.B. The libsyntax implementation doesn’t require spans to be adjacent, and I’m not sure whether or not we want it to be this powerful; ostensibly, the only spans you could have accessible are for the current invocation, but I think it would be possible to cheat this with a thread-local. Would this cause any problems?
It might also be useful to have something like this:
impl Span {
/// If `self` and `others` are all adjacent [or overlapping?], return a new span encompassing them all.
fn glue_many(&self, others: &[Span]) -> Option<Span> {...}
}
Though its implementation would be nontrivial (but also possible in client code… I think).
These APIs combined would suffice to make #[rewrite_unwraps] work as intended, as well as provide the building blocks for truly useful error reporting in procedural macros. This could be expanded on in the future, perhaps with a struct that can be used as an argument to panic! to pass a span as well as a message back to the compiler to be reported:
panic!(ProcMacroError { span: span, message: "Could not parse tokens as an expression" });