I'm currently working on a custom compiler for rust, and have run into a few diverging internal things. Some of this is easily fixed using stability attributes in the library, but some depend on knowledge of the underlying compiler (in particular, I have a custom internal lang item that isn't available on rustc, so it should only be a lang item on the custom compiler). I would like to generalize a planned feature for that compiler, which is the
have_rustc cfg item. It would be used like the other cfg items, but would serve to check compiler features. I have two potential ways this could be implemented:
- have_rustc="vendor", would apply only if vendor's rust compiler is in use. For example, the official compiler would have
have_rustc="rustc", the custom one would have
have_rustc="lccc"(lccc is the name of the project that includes this custom compiler). However,
have_rustc="rustc"would not be available on lccc, even if lccc perfectly implements the internals of rustc. I would personally lean more towards this method.
- have_rustc="vendor" would apply if the internal features (lang items, internal attributes, some unstable language features, and intrinsics are the primary ones) of the compiler provided by vendor are available, even if that compiler is not the exact one in use. In the above example,
have_rustc="rustc"would be true on the lccc compiler when run in rustc compatibility mode (specifically, if it is called through a binary with path name rustc)
With either method, it should at least warn when used, as generally the only reason to use it would be internally, within a standard library implementation. There are a few additional reasons, which is why I don't believe this should necessarily be a purely internal attribute (for example, various compilers may be further ahead on implementing various unstable features, so it could be used to switch on those features with compilers in a significant state of development for those features).