| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Evaluate repeat expression lengths as late as possible
Fixes #68567
r? @varkor
|
|
|
|
This is needed since `middle::cstore` defines another type named
`DepKind`, and we should not rely on shadowing to get the right one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Rollup of 9 pull requests
Successful merges:
- #69251 (#[track_caller] in traits)
- #69880 (miri engine: turn error sanity checks into assertions)
- #70207 (Use getentropy(2) on macos)
- #70227 (Only display definition when suggesting a typo)
- #70236 (resolve: Avoid "self-confirming" import resolutions in one more case)
- #70248 (parser: simplify & remove unused field)
- #70249 (handle ConstKind::Unresolved after monomorphizing)
- #70269 (remove redundant closures (clippy::redundant_closure))
- #70270 (Clean up E0449 explanation)
Failed merges:
r? @ghost
|
|
Liberate `rustc_ast_lowering` from `rustc`
The whole point of this PR is the very last commit, in which we remove `rustc` as one of `rustc_ast_lowering`'s dependencies, thereby improving `./x.py` parallelism and working towards https://github.com/rust-lang/rust/issues/65031.
Noteworthy:
- From `rustc::arena` we move logic into `arena`, in particular `declare_arena!`. This is then used in `rustc_ast_lowering` so that lowering has its own separate arena.
- Some linting code is unfortunately moved to `rustc_session::lint` cause its used both in `rustc_lint` and `rustc_ast_lowering`, and this is their common dependency.
- `rustc_session::CrateDisambiguator` is moved into `rustc_ast` so that `rustc::hir::map::definitions` can be moved into `rustc_hir`, so that `rustc_ast_lowering` can stop referring to `rustc::hir`.
r? @Zoxc
|
|
We can do this now that opt_associated_item doesn't have any panicking paths.
|
|
The codegen implementation already works for this, so we're:
* propagating track_caller attr from trait def to impl
* relaxing errors
* adding tests
Approved in a recent lang team meeting:
https://github.com/rust-lang/lang-team/blob/master/minutes/2020-01-09.md
|
|
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)
|
|
symbol_names: treat ReifyShim like VtableShim.
Without this, the `#[track_caller]` tests don't pass with `-Zsymbol-mangling-version=v0`, because there is a symbol name collision between the `ReifyShim` and the original definition.
cc @anp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Avoid query type in generics
There are at the moment roughly 170 queries in librustc.
The way ty::query is structured, a lot of code is duplicated for each query.
I suspect this to be responsible for a part of librustc'c compile time.
This PR reduces the amount of code generic on the query,
replacing it by code generic on the key-value types.
This is split out of #69808,
and should not contain the perf regression.
cc #65031
|
|
hir: replace "items" terminology with "nodes" where appropriate.
The newly added `HirOwnerItems` confused me before I realized that "items" there actually referred to HIR nodes, not `hir:Item` or "item-like" (which we should IMO replace with "owner").
I suspect the naming had something to do with `ItemLocalId`'s use of "item".
That is, `ItemLocalId` could be interpreted to mean one of two things:
* `IntraItemNodeId` i.e. `IntraOwnerNodeId`
* this is IMO correct, and I'd even like to rename it, but I didn't want to throw that into this PR
* `IntraOwnerItemId`
* this is what `HirOwnerItems` would seem to imply
r? @Zoxc cc @michaelwoerister @nikomatsakis
|
|
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
|
|
Refactorings to get rid of rustc_codegen_utils
r? @eddyb
cc #45276
After this, the only modules left in `rustc_codegen_utils` are
- `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc?
- ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate)
I don't mind doing either of the above as part of this PR or a followup if you want.
|
|
Prefetch some queries used by the metadata encoder
This brings the time for `metadata encoding and writing` for `syntex_syntax` from 1.338s to 0.997s with 6 threads in non-incremental debug mode.
r? @Mark-Simulacrum
|
|
|
|
codegen/mir: support polymorphic `InstanceDef`s
cc #69925
This PR modifies the use of `subst_and_normalize_erasing_regions` on parts of the MIR bodies returned from `instance_mir`, so that `InstanceDef::CloneShim` and `InstanceDef::DropGlue` (where there is a type) do not perform substitutions. This avoids double substitutions and enables polymorphic `InstanceDef`s.
r? @eddyb
cc @nikomatsakis
|
|
Compute the correct layout for variants of uninhabited enums
r? @eddyb
cc @RalfJung
fixes #69191
cc #69763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LocalDefId::from_def_id.
|
|
|
|
|
|
rustc: don't resolve Instances which would produce malformed shims.
There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known.
Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change.
By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match.
<hr/>
This was found while testing the MIR inliner with #68965, because it was trying to inline shims.
cc @rust-lang/wg-mir-opt
|
|
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
|
