Add control over the C/C++ standard

[brson]

I'm confused about our resolutions over this issue. We discussed quite a bit about controlling the C/C++ standard in use, and part of this issue was (I thought) to define C++ standard enums to pass to link_stdlib. That method is not about the standard in use though, so I'm not clear on the design here.

What I think we want is:

• Set the C89 / 90s-era C++ standards by default. There's some question though about whether we can accurately control this for all compilers
• Add a c_standard method that takes an enum and causes the builder to pass the appropriate flags
• Add a cpp_standard method that takes an enum ' '

Needs more discussion. cc @alexcrichton @sfackler @Kimundi @dtolnay @BurntSushi

[alexcrichton]

I think there's sort of a general question about whether gcc-rs should attempt to provide a guarantee about the C/C++ standard level you're developing with. The thinking was that if we did that we'd have to be pretty conservative for something that worked across a wide range of compilers.

I'd personally be wary of attempting to provide such a guarantee though. If signaling this as an intent in a cross-platform manner makes sense I think we should at least have an option to specify doing it, but it seems like a lot of possible pain for not a lot a lot of possible gain otherwise.

[brson]

Even if we don't set one by default we might want a way to select the standard in use so that users can have confidence what they are getting. I'm not sure how easy it is for users to get those flags right themselves today, maybe a dedicated method is worthwhile, like set_c_std(CStd::C89.

More generally, I don't know how easy it is to pick the correct compiler-specific flags with this crate today. I guess when people want to distinguish between compilers they probably ask the environment for the target family (or something), and if it's MSVC, do the MSVC thing, otherwise do the gcc thing?

[alexcrichton]

Yeah definitely makes sense to me to have these available, even if not set by default! Right now there's no way to query whether a compiler is msvc-like or gcc-like, it's just inference based on the target mostly.

[opilar]

MSVC has -std flag to control language standard. Can be only c++14, c++17 or c++latest.
GNU compiler's -std flag can be c++03, c++11, c++14 or c++17.
Clang -std flag can be c++11, c++14 or c++1z.

What to do if user wants to set standard which doesn't support by the compiler?

[alexcrichton]

Thanks for the investigation! Seems like we can at least do 14 and maybe 17 as well?

Perhaps we could panic for now if the standard isn't supported? That should at least give us flexibility into the future

[kornelski]

I think there's sort of a general question about whether gcc-rs should attempt to provide a guarantee about the C/C++ standard level you're developing with.

I have codebase that uses C99 features throughout, so I absolutely require a guarantee that at-least-C99 standard is supported, or my code simply won't compile.

[kornelski]

Set the C89 / 90s-era C++ standards by default.

Is it to force users needing C99 to explicitly turn it on? Current versions of clang, gcc and MSVC all default to C99 or later (or at least their best attempt at it).

[kornelski]

Please note that GCC takes -std=c89/-std=c90 very literally and disables support for // comments, which are common in C codebases, since all compilers accepted it by default for a long time.

If you set the default to -std=c89 then clang users may accidentally create broken builds for GCC users, since clang allows non-standard comments anyway.

If you want to deliberately limit C support to the lowest common denominator with older MSVC, then I suggest using -std=gnu90 for GCC.