| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(clippy::single_match)
Makes code more compact and reduces nestig.
|
|
|
|
|
|
|
|
Some of the bound restriction structured suggestions were incorrect
while others had subpar output.
|
|
Remove attribute `#[structural_match]` and any references to it
A small remaining part of https://github.com/rust-lang/rust/issues/63438.
|
|
Decouple `rustc_hir::print` into `rustc_hir_pretty`
High level summary:
- The HIR pretty printer, `rustc_hir::print` is moved into a new crate `rustc_hir_pretty`.
- `rustc_ast_pretty` and `rustc_errors` are dropped as `rustc_hir` dependencies.
- The dependence on HIR pretty is generally reduced, leaving `rustc_save_analysis`, `rustdoc`, `rustc_metadata`, and `rustc_driver` as the remaining clients.
The main goal here is to reduce `rustc_hir`'s dependencies and its size such that it can start and finish earlier, thereby working towards https://github.com/rust-lang/rust/issues/65031.
r? @Zoxc
|
|
|
|
|
|
Rename `def_span` to `guess_head_span`
r? @eddyb
|
|
|
|
correctly normalize constants
closes #70317
implements https://github.com/rust-lang/rust/issues/70125#issuecomment-602133708
r? eddyb cc @varkor
|
|
|
|
traits/fulfill: allow `stalled_on` to track `ty::Const::Infer(_)` (unused yet).
This PR addresses the representation side of #70180, but only *actually collects* `ty::Infer`s via `Ty::walk` into `stalled_on` (collecting `ty::ConstKind::Infer`s requires #70164).
However, it should be enough to handle #70107's needs (WF obligations are stalled only on the outermost type/const being an inference variable, no `walk`-ing is involved).
This is my second attempt, see #70181 for the previous one, which unacceptably regressed perf.
r? @nikomatsakis cc @nnethercote
|
|
|
|
Remove `ReClosureBound`
We now substitute external names for regions in the query response.
r? @nikomatsakis
|
|
|
|
|
|
rustc: keep upvars tupled in {Closure,Generator}Substs.
Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`.
Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods.
To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are:
* before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]`
* after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]`
You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types.
r? @nikomatsakis cc @Zoxc
|
|
Increase verbosity when suggesting subtle code changes
Do not suggest changes that are actually quite small inline, to minimize the likelihood of confusion.
Fix #69243.
|
|
remove redundant closures (clippy::redundant_closure)
|
|
|
|
more clippy fixes
* remove unused unit values (clippy::unused_unit)
* make some let-if-bindings more idiomatic (clippy::useless_let_if_seq)
* clarify when we pass () to functions (clippy::unit_arg)
* don't redundantly repeat field names (clippy::redundant_field_names)
* remove redundant returns (clippy::needless_return)
* use let instead of match for matches with single bindings (clippy::match_single_binding)
* don't convert results to options just for matching (clippy::if_let_some_result)
|
|
|
|
|
|
|
|
rustc: use LocalDefId instead of DefId in TypeckTables.
The logic in `TypeckTables`' implementation of `HashStable`, which created `DefId`s by combining a `CrateNum` from a `DefId` and a `DefIndex` from a `LocalDefId`, bothered me a bit.
I don't know how much this matters, but it works so might as well submit it.
|
|
|
|
|
|
|
|
rustc_infer: remove InferCtxt::closure_sig as the FnSig is always shallowly known.
That is, `ClosureSubsts` is always created (in `rustc_typeck::check::closure`) with a `FnSig`, as the number of inputs is known, even if they might all have inference types.
The only useful thing `InferCtxt::closure_sig` was doing is resolving an inference variable used just to get the `ty::FnPtr` containing that `FnSig` into `ClosureSubsts`.
The ideal way to solve this would be to add a constructor for `ClosureSubsts`, that combines the parent `Substs`, the closure kind, the signature, and capture types together, but for now I've went with resolving the inference types just after unifying them with the real types.
r? @nikomatsakis
|
|
|
|
|
|
|
|
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
|
|
known.
|
|
Also skip duplicated region solving entirely with `-Zborrowck=mir`.
|
|
Implement a feature for a sound specialization subset
This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use.
The plan is to then:
* Update `libcore` and `liballoc` to compile with `min_specialization`.
* Add a lint to forbid use of `feature(specialization)` (and other unsound, type system extending features) in the standard library.
* Fix the soundness issues around `specialization`.
* Remove `min_specialization`
The rest of this is an overview from a comment in this PR
## Basic approach
To enforce this requirement on specializations we take the following approach:
1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`.
2. Check for any direct use of `'static` in the substs of `impl2`.
3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate.
4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs).
## Example
Suppose we have the following always applicable impl:
```rust
impl<T> SpecExtend<T> for std::vec::IntoIter<T> { /* specialized impl */ }
impl<T, I: Iterator<Item=T>> SpecExtend<T> for I { /* default impl */ }
```
We get that the subst for `impl2` are `[T, std::vec::IntoIter<T>]`. `T` is constrained to be `<I as Iterator>::Item`, so we check only `std::vec::IntoIter<T>` for repeated parameters, which it doesn't have. The predicates of `impl1` are only `T: Sized`, which is also a predicate of impl2`. So this specialization is sound.
## Extensions
Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits.
### rustc_specialization_trait
If a trait is always applicable, then it's sound to specialize on it. We check trait is always applicable in the same way as impls, except that step 4 is now "all predicates on `impl1` are always applicable". We require that `specialization` or `min_specialization` is enabled to implement these traits.
### rustc_specialization_marker
There are also some specialization on traits with no methods, including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can.
r? @nikomatsakis
cc #31844 #67194
|
|
|
|
|
|
|
|
|
|
Currently the only difference between it and `specialization` is that
it only allows specializing functions.
|
|
|
|
|
|
|
|
|
|
|
