This still doesn't handle the case entirely correctly, requiring a more
targeted approach with a better suggestion, but at least now the
suggested syntax makes *some* sense.
Initial implementation of `#![feature(bindings_after_at)]`
Following up on #16053, under the gate `#![feature(bindings_after_at)]`, `x @ Some(y)` is allowed subject to restrictions necessary for soundness.
The implementation and test suite should be fairly complete now.
One aspect that is not covered is the interaction with nested `#![feature(or_patterns)]`.
This is not possible to test at the moment in a good way because that feature has not progressed sufficiently and has fatal errors in MIR building. We should make sure to add such tests before we stabilize both features (but shipping one of them is fine).
r? @pnkfelix
cc @nikomatsakis @matthewjasper @pcwalton
cc https://github.com/rust-lang/rust/issues/65490
Improve diagnostics for invalid assignment
- Improve wording and span information for invalid assignment diagnostics.
- Link to https://github.com/rust-lang/rfcs/issues/372 when it appears the user is trying a destructuring assignment.
- Make the equality constraint in `where` clauses error consistent with the invalid assignment error.
Add simpler entry points to const eval for common usages.
I found the `tcx.const_eval` API to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways:
- Evaluates the value of a constant without any substitutions, e.g. evaluating a static, discriminant, etc.
- Evaluates the value of a resolved instance of a constant. this happens when evaluating unevaluated constants or normalising trait constants.
- Evaluates a promoted constant.
This PR adds three new functions `const_eval_mono`, `const_eval_resolve`, and `const_eval_promoted` to `TyCtxt`, which each cater to one of the three ways `tcx.const_eval`
is normally used.
Allocate HIR on an arena 1/4
This PR is the first in a series of 4, aiming at allocating the HIR on an arena, as a memory optimisation.
1. This first PR lays the groundwork and migrates some low-hanging fruits.
2. The second PR will migrate `hir::Expr`, `hir::Pat` and related.
3. The third PR will migrate `hir::Ty` and related.
4. The final PR will be dedicated to eventual cleanups.
In order to make the transition as gradual as possible, some lowering routines receive `Box`-allocated data and move it into the arena. This is a bit wasteful, but hopefully temporary.
Nonetheless, special care should be taken to avoid double arena allocations.
Work mentored by @Zoxc.
Cleanup `lower_pattern_unadjusted` & Improve slice pat typeck
Following up on https://github.com/rust-lang/rust/pull/67318, in this PR, the HAIR lowering of patterns (`lower_pattern_unadjusted`) is cleaned up with a focus on slice patterns (in particular, some dead code is removed). Moreover, `check_pat_slice` is refactored some more.
r? @matthewjasper
Make GATs less ICE-prone.
After this PR simple lifetime-generic associated types can now be used in a compiling program. There are two big limitations:
* #30472 has not been addressed in any way (see src/test/ui/generic-associated-types/iterable.rs)
* Using type- and const-generic associated types errors because bound types and constants aren't handled by trait solving.
* The errors are technically non-fatal, but they happen in a [part of the compiler](4abb0ad273/src/librustc_typeck/lib.rs (L298)) that fairly aggressively stops compiling on errors.
closes#47206closes#49362closes#62521closes#63300closes#64755closes#67089
Fix too restrictive checks on Drop impls
Fixes#34426. Fixes#58311.
This PR completes and extends #59497 (which has been inactive for a while now).
The problem generating both issues was that when checking that the `Predicate`s of the `Drop` impl are exactly the same as the ones of the struct definition, the check was essentially performed by a simple `==` operator, which was not handling correctly HRTBs and involved `Fn` types.
The implemented solution relies on the `relate` machinery to more correctly equate `Predicate`s, and on `anonymize_late_bound_regions` to handle HRTB in a more general way. As the `Relate` trait currently is implemented only for `TraitPredicate` and `ProjectionPredicate` (and as they were the ones generating problems), `relate` is used only for them while for other `Predicate`s the equality check is kept. I'm currently considering whether it would make sense to implement the `Relate` trait also for all other `Predicate`s to render the proposed solution more general.
Add a raw "address of" operator
* Parse and feature gate `&raw [const | mut] expr` (feature gate name is `raw_address_of`)
* Add `mir::Rvalue::AddressOf`
* Use the new `Rvalue` for:
* the new syntax
* reference to pointer casts
* drop shims for slices and arrays
* Stop using `mir::Rvalue::Cast` with a reference as the operand
* Correctly evaluate `mir::Rvalue::{Ref, AddressOf}` in constant propagation
cc @Centril @RalfJung @oli-obk @eddyb
cc #64490
