| Age | Commit message (Collapse) | Author | Lines |
|---|
|
These particular patterns make it harder to experiment with alternate
representations for THIR patterns and subpatterns.
|
|
By storing `PatRange` in an Arc, and copying a few fields out of `Pat`, we can
greatly simplify the lifetimes involved in match lowering.
|
|
Rename `tcx.ensure()` to `tcx.ensure_ok()`, and improve the associated docs
This is all based on my archaeology for https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60TyCtxtEnsure.60.
The main renamings are:
- `tcx.ensure()` → `tcx.ensure_ok()`
- `tcx.ensure_with_value()` → `tcx.ensure_done()`
- Query modifier `ensure_forwards_result_if_red` → `return_result_from_ensure_ok`
Hopefully these new names are a better fit for the *actual* function and purpose of these query call modes.
|
|
Implement MIR lowering for unsafe binders
This is the final bit of the unsafe binders puzzle. It implements MIR, CTFE, and codegen for unsafe binders, and enforces that (for now) they are `Copy`. Later on, I'll introduce a new trait that relaxes this requirement to being "is `Copy` or `ManuallyDrop<T>`" which more closely models how we treat union fields.
Namely, wrapping unsafe binders is now `Rvalue::WrapUnsafeBinder`, which acts much like an `Rvalue::Aggregate`. Unwrapping unsafe binders are implemented as a MIR projection `ProjectionElem::UnwrapUnsafeBinder`, which acts much like `ProjectionElem::Field`.
Tracking:
- https://github.com/rust-lang/rust/issues/130516
|
|
|
|
|
|
|
|
It was downgraded from a query in #122721 but it can just be a vanilla
function because it's not called in `rustc_middle`.
|
|
|
|
Deduplicate operand creation between scalars, non-scalars and string patterns
just something that felt duplicated and would make pattern type handling a bit more roundabout.
|
|
|
|
|
|
r=davidtwco,RalfJung"
This reverts commit 122a55bb442bd1995df9cf9b36e6f65ed3ef4a1d.
|
|
|
|
|
|
this is required as otherwise drops of `&mut` refs count as a usage of a
'two-phase temporary' causing an ICE.
|
|
Shunpoco:issue-133117-ICE-never-false-edge-start-block, r=Nadrieril
Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block
Fixes #133117 , and close fixes #133063 , fixes #130779
In order to fix ICE-133117, at first I needed to tackle to ICE-133063 (this fixed 130779 as well).
### ICE-133063 and ICE-130779
This ICE is caused by those steps:
1. An arm has or-pattern, and all of the sub-candidates are never-pattern
2. In that case, all sub-candidates are removed in remove_never_subcandidates(). So the arm (candidate) has no sub-candidate.
3. In the current implementation, if there is no sub-candidate, the function assigns `pre_binding_block` into the candidate ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L2002-L2004)). However, otherwise_block should be assigned to the candidate as well, because the otherwise_block is unwrapped in multiple place (like in lower_match_tree()). As a result, it causes the panic.
I simply added the same block as pre_binding_block into otherwise_block, but I'm wondering if there is a better block to assign to otherwise_block (is it ok to assign the same block into pre_binding and otherwise?)
### ICE-133117
This is caused by those steps:
1. There are two arms, both are or-pattern and each has one match-pair (in the test code, both are `(!|!)`), and the second arm has a guard.
2. In match_candidate() for the first arm, it expands the second arm’s sub-candidates as well ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1800-L1805)). As a result, the root candidate of the second arm is not evaluated/modified in match_candidate(). So a false_edge_start_block is not assigned to the candidate.
3. merge_trivial_subcandidates() is called against the candidate for the second arm. It just returns immediately because the candidate has a guard. So a flase_edge_start_block is not assigned to the candidate also in this function.
4. remove_never_subcandidates() is called against the candidate. Since all sub-candidates are never-pattern. they are removed.
5. In lower_match_tree(), since there is no sub-candidate for the candidate, the candidate itself is evaluated in visit_leave_rev ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1532)). Because the candidate has no false_edge_start_block, it causes the panic.
So I modified the order of if blocks in merge_trivial_subcandidates() to assign a false_edge_start_block if the candidate doesn't have.
|
|
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
|
|
The candidate shouldn't have false_edge_start_block if it has sub candidates.
In remove_never_subcandidates(), the false_edge_start_block from the first sub candidte is assigned to a value and the value is later used if all sub candidates are removed and candidate doesn't have false_edge_start_block.
In merge_trivial_subcandidates, I leave the if block which assign a false_edge_start_block into the candidate as before I put this commit since compile panics.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
|
|
Temporarily bring back `Rvalue::Len`
r? `@compiler-errors` as requested in https://github.com/rust-lang/rust/issues/135671#issuecomment-2599580364
> However, in the mean time, I'd rather we not crunch trying to find and more importantly validate the soundness of a solution 🤔
Agreed. To fix the IMO P-critical #135671 for which we somehow didn't have test coverage, this PR temporarily reverts:
- https://github.com/rust-lang/rust/pull/133734
- its bugfix https://github.com/rust-lang/rust/pull/134371
- https://github.com/rust-lang/rust/pull/134330
cc `@scottmcm`
I added the few samples from that issue as a test, but we can add more in the future, in particular it seems `@steffahn` [will work on that](https://github.com/rust-lang/rust/issues/135671#issuecomment-2599714354).
Fixes #135671. And if we want to land this, it should also be nominated for beta backport.
|
|
r=davidtwco,RalfJung"
This reverts commit b57d93d8b9525fa261404b4cd9c0670eeb1264b8, reversing
changes made to 0aeaa5eb22180fdf12a8489e63c4daa18da6f236.
|
|
This reverts commit 7c301ecdf5e806b7aa3c44e4a185049fabbc4381, reversing
changes made to dffaad83327454430129802f240121f8c7866208.
|
|
This reverts commit e108481f74ff123ad98a63bd107a18d13035b275, reversing
changes made to 303e8bd768526a5812bb1776e798e829ddb7d3ca.
|
|
|
|
If all subcandidates have never-pattern, we should assign false_edge_start_block to the parent candidate
if it doesn't have. merge_trivial_subcandidates does so, but if the candidate has guard it returns before the assignment.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
|
|
If all subcandidates have never-pattern, the parent candidate should have otherwise_block
because some methods expect the candidate has the block.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
|
|
|
|
|
|
potential violations
|
|
as must-be-overridden
|
|
Everything's moved to `PtrMetadata` instead.
|
|
|
|
Make sure we handle `backwards_incompatible_lint` drops appropriately in drop elaboration
In #131326, a new kind of scheduled drop (`drop_kind: DropKind::Value` + `backwards_incompatible_lint: true`) was added so that we could insert a new kind of no-op MIR statement (`backward incompatible drop`) for linting purposes.
These drops were intended to have *no side-effects*, but drop elaboration code forgot to handle these drops specially and they were handled otherwise as normal drops in most of the code. This ends up being **unsound** since we insert more than one drop call for some values, which means that `Drop::drop` could be called more than once.
This PR fixes this by splitting out the `DropKind::ForLint` and adjusting the code. I'm not totally certain if all of the places I've adjusted are either reachable or correct, but I'm pretty certain that it's *more* correct than it was previously.
cc `@dingxiangfei2009`
r? nikomatsakis
Fixes #134482
|
|
|
|
|
|
|
|
|
|
|
|
Do not do if ! else, use unnegated cond and swap the branches instead
I'm tidying up my ergonomic ref counting PR and I'm going to make some small, simple and unrelated changes outside that PR, so the main PR sticks more straight to the point.
|
|
|
|
|
|
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
|
|
|
|
|
