enforce user annotations in closure signatures
Not *quite* ready yet but I'm opening anyway. Still have to finish running tests locally.
Fixes#54692Fixes#54124
r? @matthewjasper
This fixes `issue-28848.rs` -- it also handles another case that the
AST region checker gets wrong (`wf-self-type.rs`). I don't actually
think that this is the *right way* to be enforcing this constraint --
I think we should probably do it more generally, perhaps by editing
`predicates_of` for the impl itself. The chalk-style implied bounds
setup ought to fix this.
#45829 when a renamed import conflict with a previous import
Fix the suggestion when a renamed import conflict.
It check if the snipped contains `" as "`, and if so uses everything before for the suggestion.
As suggested in the feedback for #55244.
When I replaced the macro with a function, rustc started complaining
that there were two unused functions so I also removed those.
When inlining a function using the Mir inliner, we shouldn't rerun the
various Mir passes on it because the Mir has already been lowered and
that wil break various early Mir passes.
The issue in #50411 is that we've inlined a function with promotions
whose Mir has already been lowered. The promotions are then copied into
the local function and we begin to run passes on their lowered Mir
which causes the ICE.
Fixes#50411
Fixes#55001, #54744
Previously, SelectionContext would unconditionally cache the selection
result for an obligation. This worked fine for most users of
SelectionContext, but it caused an issue when used by Rustdoc's blanket
impl finder.
The issue occured when SelectionContext chose a ParamCandidate which
contained inference variables. Since inference variables can change
between calls to select(), it's not safe to cache the selection result -
the chosen candidate might not be applicable for future results, leading
to an ICE when we try to run confirmation.
This commit prevents SelectionContext from caching any ParamCandidate
that contains inference variables. This should always be completely
safe, as trait selection should never depend on a particular result
being cached.
I've also added some extra debug!() statements, which I found helpful in
tracking down this bug.
`compute_missing_ctors` is called a lot. It produces a vector, which can
be reasonably large (e.g. 100+ elements), but the vector is almost
always only checked for emptiness.
This commit changes `compute_missing_ctors` so it can be called in a
cheap way that just indicates if the vector would be empty. If
necessary, the function can subsequently be called in an expensive way
to compute the full vector.
This change reduces instruction counts for several benchmarks up to 2%.
Use a keyword in raw identifier example
That's a very small documentation fix. The text says "you can now use keywords as identifiers" but example didn't use a keyword and would work without raw identifiers.
Felix S. Klock II pointed out that this suggestion (introduced in
pull-request #43178 / eac74104) was being issued for one-field-struct
expected types (in which case it is misleading and outright wrong),
even though it was only intended for one-field enum-variants (most
notably, `Some`). Particularly tender-hearted code-historians may be
inclined to show mercy towards the author of #43178 on the grounds
that it's somewhat confusing that struct field definitions are given
in a type called `ty::VariantDef`.
Add a conditional to adhere to the original intent. (It would be
possible to generalize to structs, but not obviously net desirable.)
This adds a level of indentation, so the diff here is going to be
easier to read in ignore-whitespace mode (`-w`).
Resolves#55250.
