fix: Load proc-macros for rustc_private crates #14282
Conversation
rustbot
added
the
S-waiting-on-review
|
@bors r+ |
Veykril
changed the title
|
☀️ Test successful - checks-actions |
| let path = dir_entry.path(); | ||
| tracing::info!("p{:?}", path); | ||
| let extension = path.extension()?; | ||
| if extension == "dll" || extension == "so" { |
There was a problem hiding this comment.
macOS uses .dylib as extension. I did recommend using std::env::consts::DLL_EXTENSION instead. We can't load proc macros for another target anyway.
There was a problem hiding this comment.
Ah, that's what I forgot to do properly 👍
| None | ||
| }) | ||
| .collect(); | ||
| for p in rustc.packages() { |
There was a problem hiding this comment.
Shouldn't this check that the package is actually a proc macro? It seems like the current logic will attempt to load rustc_driver as proc macro as it is a dylib too.
There was a problem hiding this comment.
It certainly should, I assumed there would only be proc-macro dylibs in there but that's clearly not a good assumption (and even then the check is better)
minor: Fixup dylib extensions for rustc_private proc-macro loading Follow up to #14282
Fixes #13591
Verified that this makes things work in the clippy repo (like resolving
symthings for example)