| Age | Commit message (Collapse) | Author | Lines |
|
we are reverting for 1.64-beta.
|
|
This reverts commit 326646074940222d602f3683d0559088690830f4.
It was discovered that they are not implemented correctly, which
does not make them ready for stabilization.
|
|
|
|
|
|
|
|
When a binding is declared without a value, borrowck verifies that all
codepaths have *one* assignment to them to initialize them fully. If
there are any cases where a condition can be met that leaves the binding
uninitialized or we attempt to initialize a field of an unitialized
binding, we emit E0381.
We now look at all the statements that initialize the binding, and use
them to explore branching code paths that *don't* and point at them. If
we find *no* potential places where an assignment to the binding might
be missing, we display the spans of all the existing initializers to
provide some context.
|
|
|
|
|
|
|
|
|
|
Consider lifetimes when comparing types for equality in MIR validator
Closes #95978 .
|
|
|
|
|
|
Fixes #95616
|
|
|
|
Only look for complete suffixes or prefixes of irrefutable let patterns, so
that an irrefutable let pattern in a chain surrounded by refutable ones is
not linted, as it is an useful pattern.
|
|
The Box in liballoc always has a field for the allocator. It is quite
hard to support both the old and new definition of Box in cg_clif so
this change uses the new definition in this test too.
|
|
|
|
This follows changes from #67967 and converts remaining `span_bug`s into
delayed bugs, since for const items drop elaboration might be executed
on a MIR which failed borrowck.
|
|
Move generator check earlier in inlining.
Inlining into generator may create references to other generators. For instance, inlining `Pin::<&mut from_generator::GenFuture<[generator1]>>::new_unchecked` into `generator2`. This cross reference can then create cycles when computing inlining for `generator1`.
In order to avoid this kind of surprises, we forbid all inlining into generators, and rely on LLVM to do the right thing. The existing `remove-zst-query-cycle` already ICEs in inline-mir mode, so we use it as test.
Split from #91743.
|
|
|
|
Previously some code paths would fail to evaluate the rvalue, while
incorrectly indicating success with `Ok`. As a result the previous value
of lhs could have been incorrectly const propagated.
|
|
|
|
This directive isn't automatically set by compiletest or x.py, but can
be turned on manually for targets that require it.
|
|
It was replaced several years ago by the stable option `-C
overflow-checks`. The goal was to delete the `-Z` flag once users had
migrated [1]. Now that it's been several years, it makes sense to delete
the old flag.
See also the discussion on Zulip [2].
[1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097
[2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224
|
|
|
|
|
|
|
|
Querying layout of a generator requires its optimized MIR. Thus
computing layout during MIR optimization of a generator might create a
query cycle. Disable RemoveZsts in generators to avoid the issue
(similar approach is used in ConstProp transform already).
|
|
|
|
:sparkles:
|
|
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
|
|
|
|
|
|
|
|
|
|
|
|
involved
|
|
Add a test that has the right input to trigger an out-of-bounds
error when in MIR the local_decls and the normalized_input_tys don't
match in amount.
|
|
Make source-based code coverage compatible with MIR inlining
When codegenning code coverage use the instance that coverage data was
originally generated for, to ensure basic level of compatibility with
MIR inlining.
Fixes #83061
|
|
More precise spans for HIR paths
`Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path.
This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span.
This is a pre-requisite for https://github.com/rust-lang/rust/pull/82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans).
r? ````@estebank````
|
|
|
|
|
|
|
|
|
|
|
|
actual changes in behaviour
This makes `type_alias_impl_trait` not actually do anything anymore
|
|
|