Previously tidy would require that the `feature = "name_of_feature"`
part of the stability attribute was on the same line as the `#[stable(`
/ `#[unstable(` opening part of the attribute, and that `)]` was on the
same line as the last key-value pair.
That didn't work with rustfmt's preferred layout of long attributes,
which is like:
#[unstable(
feature = "c_variadic",
reason = "the `c_variadic` feature has not been properly tested on \
all supported platforms",
issue = "44930"
)]
When we normalize the types in a function signature, we may end up
resolving a projection to an opaque type (e.g. `Self::MyType` when
we have `type MyType = impl SomeTrait`). When the projection is
resolved, we will instantiate the generic parameters into fresh
inference variables.
While we do want to normalize projections to opaque types, we don't want
to replace the explicit generic parameters (e.g. `T` in `impl
MyTrait<T>`) with inference variables. We want the opaque type in the
function signature to be eligible to be a defining use of that opaque
type - adding inference variables prevents this, since the opaque type
substs now appears to refer to some specific type, rather than a generic
type.
To resolve this issue, we inspect the opaque types in the function
signature after normalization. Any inference variables in the substs are
replaced with the corresponding generic parameter in the identity substs
(e.g. `T` in `impl MyTrait<T>`). Note that normalization is the only way
that we can end up with inference variables in opaque substs in a
function signature - users have no way of getting inference variables
into a function signature.
Note that all of this refers to the opaque type (ty::Opaque) and its
subst - *not* to the underlying type.
Fixes#59342
Issue #22750
The error reporting for E0277 (the trait `X` is not implemented for `Foo`)
now checks whether `Foo` implements a trait with the same path as `X`,
which probably means that the programmer wanted to actually use only one
version of the trait `X` instead of the two.
Rework raw ident suggestions
Use heuristics to determine whethersuggesting raw identifiers is
appropriate.
Account for raw identifiers when printing a path in a `use` suggestion.
Fix#66126.
introduce benchmarks of HashSet operations
To avoid goofs such as corrected by #66280, I added benchmarks of binary HashSet operations.
Due to the fact x.py keeps recompiling the whole shebang (or at least a big part of it) whenever you touch the test code, and because piling up all tests in one file does not strike me as future proof, I tried moving the hash benches to the separate place they are for liballoc/collections/btree. But it turns out that, in a cleaned checkout, x.py still recompiles the whole shebang whenever you touch the test code (PS or when you add or delete any irrelevant file). So I'm not going to add more tests, and I doubt others will, and these tests have proven their point already, so this PR is kind of pointless
Fix cycle when debug-printing opaque types
Fixes#61577
When printing an opaque type in non-verbose mode, we use the
`tcx.predicates_of` query to retrieve the opaque type's bounds for
pretty-printing. However, the pervasiveness of logging within librustc
means that we may already be executing `tcx.predicates_of` for the
opaque type we're trying to print, leading to a cycle error.
This commit adds a new 'no queries' thread-local flag to the pretty
printer. This flag is enabled during the computation of `predicates_of`
for opaque types, and causes us to print the opaque type in 'verbose'
mode (which does not require computing any additinal queries). This
should only affect debug logging for highly nested log messages, not any
user-visible output.
