about summary refs log tree commit diff
path: root/compiler/rustc_middle/src
AgeCommit message (Collapse)AuthorLines
2023-10-02remove Key impls for types that involve an AllocIdRalf Jung-24/+0
2023-10-02MIRI -> MiriRalf Jung-1/+1
2023-10-01Auto merge of #116281 - Nadrieril:eager-const-eval, r=cjgillotbors-1/+10
Cleanup number handling in match exhaustiveness Doing a little bit of cleanup; handling number constants was somewhat messy. In particular, this: - evals float consts once instead of repetitively - reduces `Constructor` from 88 bytes to 56 (`mir::Const` is big!) The `fast_try_eval_bits` function was mostly constructed from inlining existing code but I don't fully understand it; I don't follow how consts work and are evaluated very well.
2023-10-01Move `eval_bits` optimization upstreamNadrieril-1/+10
2023-09-30add some docs to hooks/mod.rsRalf Jung-0/+5
2023-09-30Auto merge of #116254 - WaffleLapkin:nicen-traversal, r=cjgillotbors-72/+45
Assorted improvements for `rustc_middle::mir::traversal` r? `@cjgillot` I'm not _entirely_ sure about all changes, although I do like all of them. If you'd like I can drop some commits. Best reviewed on a commit-by-commit basis, I think, since they are fairly isolated.
2023-09-30dont call mir.post_mono_checks in codegenRalf Jung-44/+1
2023-09-29Remove deleted docs + better link together MIR traversing docsMaybe Waffle-2/+37
2023-09-29a small wf and clause cleanuplcnr-9/+18
2023-09-28Use `and_then` instead of while let chain to clarify `iter` scopeMaybe Waffle-1/+1
2023-09-28Remove unnecessary `&mut/ref mut` pairMaybe Waffle-1/+1
2023-09-28Don't resolve basic block data in `Postorder`Maybe Waffle-7/+6
The only usage immediately throws out the data, so.
2023-09-28`(&mut iter)` -> `iter.by_ref()`Maybe Waffle-1/+1
2023-09-28Simplify `Postorder::next`Maybe Waffle-6/+4
2023-09-28Remove `ReversePostorder` altogetherMaybe Waffle-58/+0
It was not used anywhere, instead we directly reverse postorder.
2023-09-28Remove outdated commentMaybe Waffle-2/+1
There is no `reset` anymore
2023-09-28Add a mir validation check to prevent OpaqueCast after analysis passes finishOli Scherer-0/+1
2023-09-28Rollup merge of #116211 - matthiaskrgr:clippy3, r=compiler-errorsMatthias Krüger-2/+2
more clippy complextity fixes redundant_guards, useless_format, clone_on_copy
2023-09-27fix clippy::{redundant_guards, useless_format}Matthias Krüger-2/+2
2023-09-27Auto merge of #109597 - cjgillot:gvn, r=oli-obkbors-1/+1
Implement a global value numbering MIR optimization The aim of this pass is to avoid repeated computations by reusing past assignments. It is based on an analysis of SSA locals, in order to perform a restricted form of common subexpression elimination. By opportunity, this pass allows for some simplifications by combining assignments. For instance, this pass could be able to see through projections of aggregates to directly reuse the aggregate field (not in this PR). We handle references by assigning a different "provenance" index to each `Ref`/`AddressOf` rvalue. This ensure that we do not spuriously merge borrows that should not be merged. Meanwhile, we consider all the derefs of an immutable reference to a freeze type to give the same value: ```rust _a = *_b // _b is &Freeze _c = *_b // replaced by _c = _a ```
2023-09-27Auto merge of #115887 - RalfJung:pat, r=oli-obkbors-6/+10
thir::pattern: update some comments and error type names Follow-up to [these comments](https://github.com/rust-lang/rust/pull/105750#pullrequestreview-1629697578). Please carefully fact-check, I'm new to this area of the compiler!
2023-09-27Auto merge of #116163 - compiler-errors:lazyness, r=oli-obkbors-15/+21
Don't store lazyness in `DefKind::TyAlias` 1. Don't store lazyness of a type alias in its `DefKind`, but instead via a query. 2. This allows us to treat type aliases as lazy if `#[feature(lazy_type_alias)]` *OR* if the alias contains a TAIT, rather than having checks for both in separate parts of the codebase. r? `@oli-obk` cc `@fmease`
2023-09-26subst -> instantiatelcnr-24/+12
2023-09-26Don't store lazyness in DefKindMichael Goulet-15/+21
2023-09-24Remove span from BrAnon.Camille GILLOT-12/+11
2023-09-24Add global value numbering pass.Camille GILLOT-1/+1
2023-09-23Remove GeneratorWitness and rename GeneratorWitnessMIR.Camille GILLOT-79/+26
2023-09-23Enable drop_tracking_mir by default.Camille GILLOT-82/+2
2023-09-23Auto merge of #116081 - compiler-errors:closure-captures-sized, r=cjgillotbors-0/+4
Check that closure/generator's interior/capture types are sized check that closure upvars and generator interiors are sized. this check is only necessary when `unsized_fn_params` or `unsized_locals` is enabled, so only check if those are active. Fixes #93622 Fixes #61335 Fixes #68543
2023-09-23Auto merge of #116052 - oli-obk:ceci_nest_pas_une_query, r=WaffleLapkinbors-11/+97
Add a way to decouple the implementation and the declaration of a TyCtxt method. properly addresses https://github.com/rust-lang/rust/pull/115819 accepted MCP: https://github.com/rust-lang/compiler-team/issues/395
2023-09-23Check types live across yields in generators tooMichael Goulet-1/+3
2023-09-23Check that closure's by-value captures are sizedMichael Goulet-0/+2
2023-09-22Merge `ExternProviders` into the general `Providers` structOli Scherer-0/+1
2023-09-22Have a single struct for queries and hookOli Scherer-0/+23
2023-09-22Auto merge of #115696 - RalfJung:closure-ty-print, r=oli-obkbors-11/+11
adjust how closure/generator types are printed I saw `&[closure@$DIR/issue-20862.rs:2:5]` and I thought it is a slice type, because that's usually what `&[_]` is... it took me a while to realize that this is just a confusing printer and actually there's no slice. Let's use something that cannot be mistaken for a regular type.
2023-09-22Rollup merge of #116049 - RalfJung:future-incompat, r=NilstriebMatthias Krüger-3/+6
give FutureIncompatibilityReason variants more explicit names Also make the `reason` field mandatory when declaring a lint, to make sure this is a deliberate decision.
2023-09-22Rollup merge of #116041 - compiler-errors:rigid-note, r=RalfJungMatthias Krüger-0/+5
Add note to `is_known_rigid` Adds a note requested by `@RalfJung` in https://github.com/rust-lang/rust/pull/114941#discussion_r1329963704 Let me know if there are any other fns that need documentation, I could throw them into this PR too :)
2023-09-22Add tracing instrumentation, just like queries automatically add itOli Scherer-0/+1
2023-09-22Add a way to decouple the implementation and the declaration of a TyCtxt method.Oli Scherer-11/+72
2023-09-22give FutureIncompatibilityReason variants more explicit namesRalf Jung-3/+6
2023-09-22Add note to is_known_rigidMichael Goulet-0/+5
2023-09-22Auto merge of #115920 - Zoxc:depkind-u16, r=cjgillotbors-161/+63
Move `DepKind` to `rustc_query_system` and define it as `u16` This moves the `DepKind` type to `rustc_query_system` where it's defined with an inner `u16` field. This decouples it from `rustc_middle` and is a step towards letting other crates define dep kinds. It also allows some type parameters to be removed. The `DepKind` trait is replaced with a `Deps` trait. That's used when some operations or information about dep kinds which is unavailable in `rustc_query_system` are still needed. r? `@cjgillot`
2023-09-21Auto merge of #115897 - eduardosm:check-fn-sig, r=compiler-errorsbors-0/+3
rustc_hir_analysis: add a helper to check function the signature mismatches This function is now used to check `#[panic_handler]`, `start` lang item, `main`, `#[start]` and intrinsic functions. The diagnosis produced are now closer to the ones produced by trait/impl method signature mismatch. This is the first time I do anything with rustc_hir_analysis/rustc_hir_typeck, so comments and suggestions about things I did wrong or that could be improved will be appreciated.
2023-09-21Auto merge of #115864 - compiler-errors:rpitit-sugg, r=estebankbors-1/+16
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound First commit allows us to store the span of the `async` keyword in HIR. Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in #115822. This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
2023-09-21adjust how closure/generator types and rvalues are printedRalf Jung-11/+11
2023-09-21Record asyncness span in HIRMichael Goulet-1/+16
2023-09-21Auto merge of #114399 - Zalathar:no-renumber, r=jackh726bors-11/+0
coverage: Don't bother renumbering expressions on the Rust side The LLVM API that we use to encode coverage mappings already has its own code for removing unused coverage expressions and renumbering the rest. This lets us get rid of our own complex renumbering code, making it easier to change our coverage code in other ways. --- Now that we have tests for coverage mappings (#114843), I've been able to verify that this PR doesn't make the coverage mappings worse, thanks to an explicit simplification step.
2023-09-21Move `DepKind` to `rustc_query_system` and define it as `u16`John Kåre Alsaker-161/+63
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-161/+145
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
2023-09-21Rollup merge of #115936 - oli-obk:inline_const_promotion, r=RalfJungGuillaume Gomez-3/+4
Prevent promotion of const fn calls in inline consts We don't wanna make that mistake we did for statics and consts worse by letting more code use it. r? ``@RalfJung`` cc https://github.com/rust-lang/rust/issues/76001
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 04:31:41 +0000