That condition was leftover from a refactor, and was probably not
intended. In fact it can't trigger: it would require a ConstantValue of
an integral type for which `try_eval_bits` fails. But since we only
apply `subtract_ctors` to the output of `all_ctors`, this won't happen.
SourceMap is now in the root of all rustc-specific crates, syntax_pos,
so there's no need for the trait object to decouple the dependencies
between librustc_errors and libsyntax as was needed previously.
Port erased cleanup
Just realised that the changes I made in #65965 were removed after the move of all error codes so here it is. I made them into separate commits to make the history look better this time.
r? @Mark-Simulacrum
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering
We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per https://github.com/rust-lang/rfcs/pull/2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.
r? @varkor
This does not update the use sites or delete the now unnecessary
SourceMapper trait, to allow git to interpret the file move as a rename
rather than a new file.
This is a bit unfortunate, but code needs to be able to fatally error
early on (in particular, syntax_pos after we move SourceMap there). It's
also a tiny bit of code, which means it's ultimately not that bad.
