global proc-macro! sideeffects are a terrible idea

[MaulingMonkey]

For not-yet public java interop macros I'm introducing a new attribute to share state between invokations:

#![share_state_by_voiding_rustc_semver_and_breaking_randomly_in_the_future]

Per rust-lang/reference#578, the order of proc-macro expansion is not defined, and is likely to eventually change in the future even though right now it seems to be consistently in-order. My use case is something like:

java! {
    // Declare where to source Java metadata from:
    extern jdk "adopt-openjdk-13";
    extern jar "my-class.jar";
    // Generate Rust bindings for calling into Java:
    define import java.lang.*;
    define import my.Class;
    ...
}

// ...in a galaxy far far away...
java! {
    impl class my.Class { // This should be validated against the extern ed SDKs
        fn some_native_method(&env, this, a: u32, b: u32) -> u32 {
            ...
        }
    }
}

Alternatives

• Duplicate defs every time (seems lame / a bad idea, doesn't play well with codegen?)
• Have a single java! per crate that consumes the entire crate src (maybe a #![java] proc macro?)
• When the first macro is evaluated, or via a build script:
  • Could pre-scan crate src once for externs/defines to pre-populate
  • Could read sidecar configuration files
  • Could read Cargo.toml package metadata