Fall back to rustc's default value for crt-static

[madsmtm]

And parse more information from rustc, to prepare for doing more of #1249 and #268.

The net result is fairly small, it's that 37 targets (the full list is all targets with crt-static in their features table) now have -static passed when compiling outside a build script.

They should already have been passed when compiling in a build script, but that doesn't work, seemingly because of a bug in either rustc or Cargo that prevents the flag from propagating to CARGO_CFG_TARGET_FEATURE?

See also #1074, it sounds like this flag isn't that important?

[madsmtm]

Opened rust-lang/cargo#14778 for the issue of Cargo not passing this in CARGO_CFG_TARGET_FEATURE.

There is not really a way that cc can detect whether we're hitting that bug, or if the flag is just absent because the user requested that it is absent, apart from maybe reading CARGO_ENCODED_RUSTFLAGS?

[NobodyXu]

Thanks this mostly LGTM

Since there's a cargo bug, I think we should wait until upstream provides a clear answer to the issue.

[NobodyXu]

Nit:

Shall we have a check for duplicate value, just in case rustc gives us some invalid output?

[madsmtm]

Good idea

[NobodyXu]

The generated file is getting larger and I'm slightly worried about the compile-time/binary size.

It probably would be fine for now and we should not hesitate adding more, if it eases maintenance burden and reduce hardcoded values.

[madsmtm]

I suspect that the features here are going to be fairly important for runtime performance and correctness, but yeah, I do understand your worry.

I guess if we wanted to decrease binary size, we could parse them into a &[Feature] beforehand?

[NobodyXu]

Hmmm...in terms of binary size it might be worse, there's a lot of small strings.

If we have small string optimization like docs.rs/compact-str then it might makes sense to do it.

Looking at the string, most are 3-5B, smaller than fat pointer, some are around ~10B, the longest is 20B.

Doing SSO would require quite some work and unsafe

[NobodyXu]

On the other hand, we could replace all this features with a boolean since all we need to know is if cry-static is included in the feature or not.

If we need more features later, then we can introduce them later, and probably use an enum which is more efficient than &str

[NobodyXu]

On the other hand, we could replace all this features with a boolean since all we need to know is if cry-static is included in the feature or not.

If we need more features later, then we can introduce them later, and probably use an enum which is more efficient than &str

[NobodyXu]

If we want to reduce the binary size/compilation time, then I could think of two ideas:

First, split the target and TargetInfo into two arrays, this would help simplify the array, and might make binary search faster as more target can be in the cache.

For TargetInfo, we can store the string inline.

We can internalise the string into a one big &str and refer to it via index, we can simply use a u16 for base pointer.

The simplest impl is to use HashSet in gen-target-info to dedup them, and then concat them into one giant string, each terminated by \0 and assign them each a u16 based on the length within the giant string.

That will compress 16B &'static str on 64-bit platform to 2B, and should improve compile-time as well.

Though it looks like something out of scope for this ticket.

[NobodyXu]

So for this PR, cc @madsmtm I just want you to replace features: &str with a crt_static: boolean, that would be good enough.

The rest of the idea should be discussed and completed in a different PR.

[NobodyXu]

Opened rust-lang/cargo#14778 for the issue of Cargo not passing this in CARGO_CFG_TARGET_FEATURE.

There is not really a way that cc can detect whether we're hitting that bug, or if the flag is just absent because the user requested that it is absent, apart from maybe reading CARGO_ENCODED_RUSTFLAGS?

cc @madsmtm given that the upstream probably won't fix CARGO_CFG_TARGET_FEATURE very soon, shall we read from CARGO_ENCODED_RUSTFLAGS instead?

[mrkajetanp]

shall we read from CARGO_ENCODED_RUSTFLAGS instead?

I should be able to post my PR for #1254 this week which introduces reading CARGO_ENCODED_RUSTFLAGS and adding cc flags based on that so it could come in handy for this?
Though in the general case I don't think it's a good idea to pass target features from there, instead target features should be read from CARGO_CFG_TARGET_FEATURE and managed separately. But if there's a bug like in this case, a stopgap solution could go there just fine.