I'm looking at adding a
-Z allow-features=x,y,z command-line flag to the compiler, and it looks like all the list options like this are space-separated
unfortunately, I can't figure out a way to put a space inside a command line option in my test
so my question is..
1. is space-separated the right format for an option like this?
2. how the heck do I test this?
note that if I specify the option more than once, it overwrites the list rather than appending
here's my PR: #59169
@tmandry I think @Pietro Albini added a flag that lets you specify arbitrary crate-level attributes
so it might be worth just using that instead? I forget the name though
Oh, I misinterpreted what the flag does
I would maybe think about reworking the flag to be a crate attribute since that's easier to test etc and then just rely on
-Z crate-attrs to actually specify it from build systems and the like
hmm, adding it as a crate attribute seems more potentially controversial
would that require an RFC?
I think as long as it's unstable I wouldn't expect it to be
So one other thing that I might suggest is to perhaps use something like
syn to parse your crates and implement this as a tidy-style rule?
@tmandry But in terms of
-Z argument I'd personally feel better about comma-sep (features can't have commas in them so should be fairly easy to implement)
comma-separated should be easy to test and is what I would have expected personally
I just didn't go that route because I couldn't find any other comma-separated options :)
@tmandry I think that might be partially because we just don't have many options
OTOH, you could also do "only one feature per option" and then just all the options are joined together (additive)
Features are never stable so I would expect the
-Z flag to also never be stable
(features == the gating mechanism itself and the names we assign in
okay, I think I'll make it comma-separated then
related issue: how do I run the
I can never remember