O(n) fallback::Span::start/end

[Axel-Reactor]

I use syn to parse Rust files outside of Rust macros and I noticed really slow performance in fallback::Span.

The problem seems like that there is a SOURCE_MAP thread local that only keeps growing. I never destroy the threads, it's a thread pool. Now I could try to create new threads every time I call into syn, but this seems silly.

Also, why is SourceMap::files a Vec? It seems like the spans in FileInfo can never overlap, so why not just use a BTreeMap sorted by span.start to look up the files? At least then it would be O(log n) for look ups even if it keeps growing.

[dtolnay]

You should be invalidating spans using https://docs.rs/proc-macro2/1/proc_macro2/extra/fn.invalidate_current_thread_spans.html.

[Axel-Reactor]

Didn't know about this. That's kind of bad UX though when syn itself doesn't expose any of this to the outside?