Check for proc_macro before -Ctarget-features=+crt-static

[bjorn3]

This makes it possible to compile proc macros when -Ctarget-features=+crt-static is used

[rust-highfive]

r? @oli-obk

(rust_highfive has picked a reviewer for you, use r? to override)

[oli-obk]

Do you think it's reasonable to build a test for this behaviour? I worry that other subtle changes may break this again, but that may be overcautious.

[petrochenkov]

r? @petrochenkov
This is a tricky case with future-compatibility implications, cc #71651 #72510.
I'd prefer not to touch it for now.

(I think one proper solution here is supporting per crate or per crate type rustc flags in cargo.)

[bjorn3]

This only changes behaviour for proc-macros, which are not guaranteed to be usable for anything other than rustc usage anyway. We could make proc-macros executables if we wanted or even use our own object format. If this were to apply to dylibs this could indead break stuff, but for proc-macros this is solely a bug fix.

[petrochenkov]

Well, yeah, but rust-lang/cargo#7811 and rust-lang/cargo#8441 are on its way, and I'd want to develop some holistic solution to this on rustc side, so I'll take a liberty to close this for now, it's not super urgent.

In general, I still think rustc is a wrong abstraction level here, it the user explicitly says to build a proc macro crate with +crt-static, then the compiler should obey, perhaps there are reasons.
A higher level build system should ensure that specifying +crt-static for executables doesn't do collateral damage on other crates, and it's unfortunate that Cargo sometimes shies away from being a proper build system. If it supports build targets (in CMake terminology), then it should support per-target configuration as well.