`--extern mycrate=path/to/my/crate/with/random.suffix` fails with "file name should be lib*.rlib or lib*.so"

macro.rs:

extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn your_macro(_attr: TokenStream, item: TokenStream) -> TokenStream {
    // Macro implementation
    item
}

main.rs:

extern crate macros;

#[macros::your_macro]
fn main() {
    println!("Hello, world!");
}

This works:

rustc --crate-type proc-macro macros.rs -o libmacros.dylib
rustc main.rs --extern macros=libmacros.dylib

This doesn't:

rustc --crate-type proc-macro macros.rs -o libmacros.so
rustc main.rs --extern macros=libmacros.so

error: extern location for macros is of an unknown type: libmacros.so
 --> main.rs:4:1
  |
4 | extern crate macros;
  | ^^^^^^^^^^^^^^^^^^^^

error: file name should be lib*.rlib or lib*.dylib
 --> main.rs:4:1
  |
4 | extern crate macros;
  | ^^^^^^^^^^^^^^^^^^^^

error[E0463]: can't find crate for `macros`
 --> main.rs:4:1
  |
4 | extern crate macros;
  | ^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0463`.

This has come up in Rust-For-Linux where we'd like to always use the .so suffix, but this causes the build to fail on macOS. If we change the suffix to .dylib, it works on macOS, but not Linux.

Reproduce the issue with the provided macro.rs and main.rs commands, then trace rustc's handling of the --extern path and accepted artifact suffixes. Check how the platform-specific .dylib and .so cases are validated; done means the intended .so suffix works on macOS without regressing the existing .dylib and Linux behavior.