| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Merge `PatKind::Path` into `PatKind::Expr`
Follow-up to #134228
We always had a duplication where `Path`s could be represented as `PatKind::Path` or `PatKind::Lit(ExprKind::Path)`. We had to handle both everywhere, and still do after #134228, so I'm removing it now.
|
|
|
|
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.
|
|
Lower index bounds checking to `PtrMetadata`, this time with the right fake borrow semantics 😸
Change `Rvalue::RawRef` to take a `RawRefKind` instead of just a `Mutability`. Then introduce `RawRefKind::FakeForPtrMetadata` and use that for lowering index bounds checking to a `PtrMetadata`. This new `RawRefKind::FakeForPtrMetadata` acts like a shallow fake borrow in borrowck, which mimics the semantics of the old `Rvalue::Len` operation we're replacing.
We can then use this `RawRefKind` instead of using a span desugaring hack in CTFE.
cc ``@scottmcm`` ``@RalfJung``
|
|
|
|
|
|
r=davidtwco,RalfJung"
This reverts commit 122a55bb442bd1995df9cf9b36e6f65ed3ef4a1d.
|
|
|
|
|
|
|
|
Use short ty string for move errors
```
error[E0382]: use of moved value: `x`
--> bay.rs:14:14
|
12 | fn foo(x: D) {
| - move occurs because `x` has type `(((..., ..., ..., ...), ..., ..., ...), ..., ..., ...)`, which does not implement the `Copy` trait
13 | let _a = x;
| - value moved here
14 | let _b = x; //~ ERROR use of moved value
| ^ value used here after move
|
= note: the full type name has been written to 'bay.long-type-14349227078439097973.txt'
= note: consider using `--verbose` to print the full type name to the console
help: consider cloning the value if the performance cost is acceptable
|
13 | let _a = x.clone();
| ++++++++
```
Address 4th case in #135919.
|
|
```
error[E0382]: use of moved value: `x`
--> bay.rs:14:14
|
12 | fn foo(x: D) {
| - move occurs because `x` has type `(((..., ..., ..., ...), ..., ..., ...), ..., ..., ...)`, which does not implement the `Copy` trait
13 | let _a = x;
| - value moved here
14 | let _b = x; //~ ERROR use of moved value
| ^ value used here after move
|
= note: the full type name has been written to 'bay.long-type-14349227078439097973.txt'
= note: consider using `--verbose` to print the full type name to the console
help: consider cloning the value if the performance cost is acceptable
|
13 | let _a = x.clone();
| ++++++++
```
|
|
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>
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #135542 (Add the concrete syntax for precise capturing to 1.82 release notes.)
- #135700 (Emit single privacy error for struct literal with multiple private fields and add test for `default_field_values` privacy)
- #135722 (make it possible to use ci-rustc on tarball sources)
- #135729 (Add debug assertions to compiler profile)
- #135736 (rustdoc: Fix flaky doctest test)
- #135738 (Replace usages of `map_or(bool, ...)` with `is_{some_and|none_or|ok_and}`)
- #135747 (Rename FileName::QuoteExpansion to CfgSpec)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Always force non-trimming of path in `unreachable_patterns` lint
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`.
This was verified to fix https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite.
Fix #135289.
|
|
|
|
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>
|
|
Replace tuple with struct and remove unnecessary early return.
|
|
|
|
|
|
constant as pattern
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Fix #134764.
|
|
|
|
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`.
This was verified to fix https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite.
Fix #135289.
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #134228 (Exhaustively handle expressions in patterns)
- #135194 (triagebot: mark tidy changes with a more specific `A-tidy` label)
- #135222 (Ensure that we don't try to access fields on a non-struct pattern type)
- #135250 (A couple simple borrowck cleanups)
- #135252 (Fix release notes link)
- #135253 (Revert #131365)
Failed merges:
- #135195 (Make `lit_to_mir_constant` and `lit_to_const` infallible)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
potential violations
|
|
|
|
|
|
Lower Guard Patterns to HIR.
Implements lowering of [guard patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see the [tracking issue](#129967)) to HIR.
|
|
turn rustc_box into an intrinsic
I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
|
|
rustc_intrinsic: support functions without body
We synthesize a HIR body `loop {}` but such bodyless intrinsics.
Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.
I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;)
r? `@oli-obk`
|
|
as must-be-overridden
|
|
|
