Consider querying the underlying rust{,do}c version and make certain behaviors dependent on it

[fmease]

Possibly controversial :P

We should gate this behind a flag like e.g., -k/--compat to avoid executing an extra rustc process when it's unneeded in most cases. Description for -k could be sth. akin to Enable compatibility layer for older rust{,do}c version (well, is "layer" really the correct choice of word for that?).

Use cases:

• Consider querying the underlying rust{,do}c version and make certain behaviors dependent on it #20 (comment)
• Consider querying the underlying rust{,do}c version and make certain behaviors dependent on it #20 (comment)
• Consider querying the underlying rust{,do}c version and make certain behaviors dependent on it #20 (comment)
• Consider querying the underlying rust{,do}c version and make certain behaviors dependent on it #20 (comment)

[fmease]

For example, this would allow us to make the "context-sensitive" edition aliases S (latest stable edition) and E ("bleeding edge": latest edition, no matter if stable or unstable) work with older rustc/rustdoc versions, too. Potentially 'useful' when manually bisecting issues. Idk, if that's a sensible behavior tho.

[fmease]

Another example would be -#/--internals which corresponds to -Zverbose-internals in recent rustc/rustdoc versions but used to correspond to -Zverbose. Again, this would be useful when bisecting.

[fmease]

A big one: Compiletest directives. In older versions, we could switch to the pre-ui_test flavor (// XXX instead of //@ XXX). Tho that'd be annoying to add support for for potentially little gain.

[fmease]

Another use case: Until very recently rustdoc didn't treat - as a STDIN marker. So for older rustc/rustdoc versions #17 (#8) will probably fail / not work properly. Querying the version might allow us to find a workaround for older rustdoc versions.

[fmease]

We could also consider adding a more aggressive version of that mechanism/mode enabled via -kk / --compat --compat which "blindly" replaces "verbatim" program arguments to achieve compatibility. "Verbatim" program arguments are ones passed after -- on the CL, via the env vars RUST{,DO}C_FLAGS or directives like //@ compile-flags.

This would allow us to also remap verbatim flags like -Zverbose-internals (→ -Zverbose) and -Zparse-crate-root-only (→ -Zparse-only) at the risk of butchering rust{,do}c invocation(s) and without guaranteeing that we properly detect "version-dependent" flags. I don't know how to phrase this better. Ah, maybe "we admit false positives and negatives". Basically, I don't necessarily want to guarantee that we support forms like -Z verbose-internals (two program arguments), "-Z verbose-internals" (one argument, space) and -Z=verbose-internals (equals (is that even accepted?)) (← admitting false negatives) or notice that in e.g. --crate-name -Zverbose-internals, rust{,do}c actually interprets -Zverbose-internals as the crate name because getopts is super naive, jeez (← admitting false positives).

[fmease]

Tracking: Rename of directives normalize-std{out,err}-test → normalize-std{out,err}.