proc_macro::is_available()

[dtolnay]

This PR adds proc_macro::is_available() -> bool to determine whether proc_macro has been made accessible to the currently running program.

The proc_macro crate is only intended for use inside the implementation of procedural macros. All the functions in the crate panic if invoked from outside of a procedural macro, such as from a build script or unit test or ordinary Rust binary.

Unfortunately those panics made it impossible for libraries that are designed to support both macro and non-macro use cases (e.g. Syn) to be used from binaries that are compiled with panic=abort. In panic=unwind mode we're able to attempt a proc macro call inside catch_unwind and use libproc_macro's result if it succeeds, otherwise fall back to a non-macro alternative implementation. But in panic=abort there was no way to determine which implementation needs to be used.

r? @eddyb
attn: @petrochenkov@adetaylor
ref: dtolnay/cxx#130

[dtolnay]

Reassigning per #71268 (comment) because @​eddyb is occupied.

r? @petrochenkov

[petrochenkov]

LGTM, but it needs a tracking issue.

FCP and official team approval can be done during stabilization.

[dtolnay]

@bors r=petrochenkov

[bors]

📌 Commit 3bd742f has been approved by petrochenkov

[eddyb]

Seems fine, the panic=abort situation leaves us no other options.

cc @mystor, who, IIRC, wanted a "default server" which would eliminate the need for proc-macro2.

[mystor]

Something like a fallback server could make is_available not make as much sense, as it could theoretically always be true. That being said, I think fixing the panic-catching jank within proc-macro2 is worth that potential future confusion, especially considering that (to my knowledge) there's no existing plan or design for a fallback proc_macro server.