Improve feature handling

[powerboat9]

This includes a program, written using flex and bison, to extract information on unstable features from rustc source code and save it to a header file.

The script does fetch files from https://github.com/rust-lang/rust (the official rustc git repository), which should be alright, as it's only intended to be run by maintainers.

See https://doc.rust-lang.org/unstable-book/ for information on unstable features.

[powerboat9]

Note that the movements of rust-feature.cc and rust-feature-gate.cc into a subdirectory break incremental builds. Run rm gcc/rust/{,.deps/}rust-feature{,-gate}.* in the build directory to fix.

[iains]

This vendors some of rustc_feature 1.49 and generates a list of features by parsing the vendored code.

I think the covering note would usefully contain more information;

• what the data is needed for
• where it comes from
• how it would be changed

maybe?
perhaps this is obvious to folks working closely with the project - but it is less so to GCC reviewers

[powerboat9]

@iains I've added a link (https://doc.rust-lang.org/unstable-book/) and added a bit to the first paragraph of the commit message

[CohenArthur]

I'm not sure this is the best way to go about this. The format used by rustc for declaring features is not stable, so it might as well change in version 1.90 and the parser will require modifications. I think I would rather see something simpler, but if everyone agrees with this PR's approach then I'm okay with it too

[powerboat9]

The parser will almost certainly need modifications in the future -- I'm just not sure how else to do this, aside from trying to manually update rust-feature.h and rust-feature.cc

[CohenArthur]

personally I think that manually updating rust-feature.{cc, h} every time we do a Rust version bump is fine. It won't happen that often (at least for now), and I think it can be achieved easily with a good editor and sed-fu.

I'm really not a fan of yacc/lex but as I said if others are okay with it then that's fine with me - but my opinion is that I'd rather be the one to manually update our features every time rather than maintain a yacc/lex parser

[iains]

I'd imagine that a manual process could use awk, if sed was not enough - and perhaps if it's a "once every two years" and "the result is committed to the repo" then having a built tool to do it is overkill (not a particular fan of flex/bison either .. not really a fan of awk ;) ) ..
,, maybe the simplest approach is easiest to maintain.

[powerboat9]

If we don't skip versions, we'll need to do the update 40+ times. Someone could reimplement this PR in awk or sed, or just manually do the updates, but I'd think either would require much more effort. The maintenance required to keep this updated should be minimal, but I'd be willing to do it whatever the case.

[powerboat9]

I've moved the script* to contrib/rust and adjusted things a bit so that only maintainers have to run it.

[CohenArthur]

@powerboat9 I think we will be skipping versions honestly, I don't think there is much point trying to have every single version implemented at different stages during the project's life. Since the main difference between versions is unstable features, if we try and implement every single version, we will run into situations where we implement a feature and then disable it in a few version bumps.

This can also happen with doing big updates obviously, but less often

[powerboat9]

This code just makes sure that the list of recognized features is up to date

[powerboat9]

Now depends on #4107

[powerboat9]

Would it be better if I left the script out-of-tree?