Could not recognize proc macro dynamic libraries compiled with Rust =1.47.0

[qryxip]

In Rust 1.47.0, ListMacro query fails with a little weird message.

❯ function list-macro () {
>   cargo "+$1" check -q --message-format json |
>     jq -c 'select(.reason == "compiler-artifact" and .target.kind == ["proc-macro"]) | {"ListMacro": {"lib": .filenames[]}}' |
>     $2 proc-macro |
>     jq
> }
❯ list-macro 1.48.0 ./rust-analyzer-2021-07-12
{
  "ListMacro": {
    "macros": [
      [
        "nop",
        "FuncLike"
      ],
      [
        "identity",
        "FuncLike"
      ]
    ]
  }
}
❯ list-macro 1.48.0 ./rust-analyzer-2021-07-19
{
  "ListMacro": {
    "macros": [
      [
        "nop",
        "FuncLike"
      ],
      [
        "identity",
        "FuncLike"
      ]
    ]
  }
}
❯ list-macro 1.47.0 ./rust-analyzer-2021-07-12
{
  "ListMacro": {
    "macros": [
      [
        "nop",
        "FuncLike"
      ],
      [
        "identity",
        "FuncLike"
      ]
    ]
  }
}
❯ list-macro 1.47.0 ./rust-analyzer-2021-07-19
{
  "Error": {
    "code": "ExpansionError",
    "message": "Cannot create expander for /home/ryo/src/local/play-expand-macros/target/debug/deps/libmy_macros_impl-e1f836fa719da873.so: Io(Custom { kind: Other, error: StreamHeader { byte: 141 } })"
  }
}

(Of course) unresolved-proc-macro warnings show up for Rust 1.47.0.

• Target: x86_64-unknown-linux-gnu
• OS: GNU/Linux (Arch Linux)

[lnicola]

CC @alexjg it looks like we should support the 1.47 proc macro ABI, but we fail to load those macros because of some differences in the version metadata. Do you happen to remember how this worked?

[lnicola]

Actually, it looks like it was working before #9550.

[lnicola]

@qryxip I'd suggest upgrading to a more recent version of the compiler.

[alexjg]

From what I can tell this is occurring in proc_macro_api::version::read_version. The StreamHeader {..} refers to the fact that for some reason the Snappy compression header on the file the read_version function is attempting to read from is invalid. I'm still trying to figure out why that's happening but I don't think the problem is to do with the ABI as we haven't even loaded the dylib at that point.

[bjorn3]

Rustc 1.48.0 switched to snappy as dylib metadata compression method: rust-lang/rust@574f6be Rustc 1.47.0 still used flate2 which rust-analyzer doesn't understand how to decompress.

[lnicola]

Yeah, it's the compression. I guess the ABI version is correct, but we don't actually support 1.47. I'm not sure it's worth adding deflate for it, since we were only planning to support the most recent stable compiler anyway.

@alexjg my question was rather "why do we think we support 1.47 when we don't".

[alexjg]

Ah gotcha. I inferred the 1.47 support from this code in proc_macro_api::ProcMacroClient::by_dylib_path

    pub fn by_dylib_path(&self, dylib_path: &Path) -> Vec<ProcMacro> {
        let _p = profile::span("ProcMacroClient::by_dylib_path");
        match version::read_dylib_info(dylib_path) {
            Ok(info) => {
                if info.version.0 < 1 || info.version.1 < 47 {
                    eprintln!("proc-macro {} built by {:#?} is not supported by Rust Analyzer, please update your rust version.", dylib_path.to_string_lossy(), info);
                }
            }
            Err(err) => {
                eprintln!(
                    "proc-macro {} failed to find the given version. Reason: {}",
                    dylib_path.to_string_lossy(),
                    err
                );
            }
        }
     }

I didn't actually test with 1.47 however. I've now tested and this does work with 1.48, and stable is well ahead of that now. It might make sense to just rename all the 1.47 stuff to 1.48 (i.e Abi_1_47 becomes Abi_1_48 etc.).