Miguel Ojeda

@Kixunil I agree it makes them less useful, of course -- it is a fact that less users would be able to use them. I also acknowledged the ecosystem split...

> I guess the difference is that @ojeda suggested checking compiler flag while the correct behavior would be to detect `compile_error` behind (correct) cfg. No, I didn't suggest that. In...

> adding extra verbosity to the diagnostic There is no extra verbosity for the common case with what I suggested. > possible particular set of circumstances that we don't know...

So there is the lint discussion and the soundness discussion (which is why we were all hiding the latter as off-topic). For the former, yes, my suggestion was about the...

> It seems to me we're missing the right tool to deal with these situations. Some kind of way to have a different interface for the same type, or something...

I would still prefer that we go with pre-filling, thus making it explicit for the user as well as making the edition easy to change.

@mattgodbolt Yeah, that is exactly the flow I was thinking. > Then there's exactly one pre-fill which must be --edition=LATEST as that's what the user will see whenever they pick...

I have added the user-editable suggestion to https://github.com/compiler-explorer/compiler-explorer/issues/3100 (from https://github.com/compiler-explorer/compiler-explorer/issues/3765#issuecomment-1668478130), simplified the wording and updated it with some of the recent developments (it was fairly old). Thus the proposal now...

> Constants using `#define` in a C header file do not have a type. They are inserted by the preprocessor as a literal where needed. It is true they are...

The macro idea is discussed at https://github.com/rust-lang/rust-bindgen/issues/1594, perhaps the discussion around that should be moved there. > However, `bindgen` also discards information. Specifically, it converts an integer literal to a...