about summary refs log tree commit diff
path: root/compiler/rustc_middle/src/mir
AgeCommit message (Collapse)AuthorLines
2024-11-19additional `TypingEnv` cleanupslcnr-4/+1
2024-11-19`InterpCx` store `TypingEnv` instead of a `ParamEnv`lcnr-15/+17
2024-11-19move `fn is_item_raw` to `TypingEnv`lcnr-3/+3
2024-11-19Auto merge of #133164 - RalfJung:promoted-oom, r=jieyouxubors-2/+13
interpret: do not ICE when a promoted fails with OOM Fixes https://github.com/rust-lang/rust/issues/130687 try-job: aarch64-apple try-job: dist-x86_64-linux
2024-11-18interpret: do not ICE when a promoted fails with OOMRalf Jung-2/+13
2024-11-18use `TypingEnv` when no `infcx` is availablelcnr-59/+67
the behavior of the type system not only depends on the current assumptions, but also the currentnphase of the compiler. This is mostly necessary as we need to decide whether and how to reveal opaque types. We track this via the `TypingMode`.
2024-11-17Auto merge of #132566 - saethlin:querify-mir-collection, r=cjgillotbors-15/+20
Querify MonoItem collection Factored out of https://github.com/rust-lang/rust/pull/131650. These changes are required for post-mono MIR opts, because the previous implementation would load the MIR for every Instance that we traverse (as well as invoke queries on it). The cost of that would grow massively with post-mono MIR opts because we'll need to load new MIR for every Instance, instead of re-using the `optimized_mir` for every Instance with the same DefId. So the approach here is to add two new queries, `items_of_instance` and `size_estimate`, which contain the specific information about an Instance's MIR that MirUsedCollector and CGU partitioning need, respectively. Caching these significantly increases the size of the query cache, but that's justified by our improved incrementality (I'm sure walking all the MIR for a huge crate scales quite poorly). This also changes `MonoItems` into a type that will retain the traversal order (otherwise we perturb a bunch of diagnostics), and will also eliminate duplicate findings. Eliminating duplicates removes about a quarter of the query cache size growth. The perf improvements in this PR are inflated because rustc-perf uses `-Zincremental-verify-ich`, which makes loading MIR a lot slower because MIR contains a lot of Spans and computing the stable hash of a Span is slow. And the primary goal of this PR is to load less MIR. Some squinting at `collector profile_local perf-record +stage1` runs suggests the magnitude of the improvements in this PR would be decreased by between a third and a half if that flag weren't being used. Though this effect may apply to the regressions too since most are incr-full and this change also causes such builds to encode more Spans.
2024-11-12Handle infer vars in anon consts on stableBoxy-0/+3
2024-11-12Querify MonoItem collectionBen Kimock-15/+20
2024-11-12Consolidate type system const evaluation under `traits::evaluate_const`Boxy-11/+9
mew
2024-11-10Rollup merge of #132675 - Zalathar:empty-spans, r=jieyouxuMatthias Krüger-8/+7
coverage: Restrict empty-span expansion to only cover `{` and `}` Coverage instrumentation has some tricky code for converting a coverage-relevant `Span` into a set of start/end line/byte-column coordinates that will be embedded in the CGU's coverage metadata. A big part of this complexity is special code for handling empty spans, which are expanded into non-empty spans (if possible) because LLVM's coverage reporter does not handle empty spans well. This PR simplifies that code by restricting it to only apply in two specific situations: when the character after the empty span is `{`, or the character before the empty span is `}`. (As an added benefit, this means that the expanded spans no longer extend awkwardly beyond the end of a physical line, which was common under the previous implementation.) Along the way, this PR also removes some unhelpful code for dealing with function source code spread across multiple files. Functions currently can't have coverage spans in multiple files, and if that ever changes (e.g. to properly support expansion regions) then this code will need to be completely overhauled anyway.
2024-11-09make return type of get_alloc_info a struct, and reduce some code ↵Ralf Jung-3/+83
duplication with validity checking
2024-11-08coverage: Remove unhelpful code for handling multiple files per functionZalathar-8/+7
Functions currently can't have mappings in multiple files, and if that ever changes (e.g. to properly support expansion regions), this code will need to be completely overhauled anyway.
2024-11-04ty::BrK -> ty::BoundRegionKind::KMichael Goulet-1/+4
2024-11-03compiler: Directly use rustc_abi in metadata and middleJubilee Young-13/+13
Stop reexporting ReprOptions from middle::ty
2024-11-01Show actual MIR when MIR building forgot to terminate blockbjorn3-22/+24
This makes it significantly easier to debug bugs of this kind.
2024-10-31stop using `ParamEnv::reveal` while handling MIRlcnr-17/+14
2024-10-31`ConstCx` stop using `ParamEnv::reveal`lcnr-6/+17
2024-10-26Rollup merge of #132168 - fee1-dead-contrib:fxclean, r=compiler-errorsMatthias Krüger-4/+2
Effects cleanup - removed extra bits from predicates queries that are no longer needed in the new system - removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers r? compiler-errors
2024-10-26Effects cleanupDeadbeef-4/+2
- removed extra bits from predicates queries that are no longer needed in the new system - removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers
2024-10-25tcx.is_const_fn doesn't work the way it is described, remove itRalf Jung-2/+2
Then we can rename the _raw functions to drop their suffix, and instead explicitly use is_stable_const_fn for the few cases where that is really what you want.
2024-10-23fix a couple clippy:complexitysMatthias Krüger-2/+2
double_parens filter_map_identity needless_question_mark redundant_guards
2024-10-23nightly feature tracking: get rid of the per-feature bool fieldsRalf Jung-1/+1
2024-10-21Auto merge of #130950 - compiler-errors:yeet-eval, r=BoxyUwUbors-5/+13
Continue to get rid of `ty::Const::{try_}eval*` This PR mostly does: * Removes all of the `try_eval_*` and `eval_*` helpers from `ty::Const`, and replace their usages with `try_to_*`. * Remove `ty::Const::eval`. * Rename `ty::Const::normalize` to `ty::Const::normalize_internal`. This function is still used in the normalization code itself. * Fix some weirdness around the `TransmuteFrom` goal. I'm happy to split it out further; for example, I could probably land the first part which removes the helpers, or the changes to codegen which are more obvious than the changes to tools. r? BoxyUwU Part of https://github.com/rust-lang/rust/issues/130704
2024-10-19Rename normalize to normalize_internal, remove unnecessary usagesMichael Goulet-1/+1
2024-10-19Get rid of const eval_* and try_eval_* helpersMichael Goulet-5/+13
2024-10-19interpret errors: add map_err_kind, rename InterpError -> InterpErrorKindRalf Jung-36/+47
2024-10-14Remove `Engine::new_gen_kill`.Nicholas Nethercote-7/+0
This is an alternative to `Engine::new_generic` for gen/kill analyses. It's supposed to be an optimization, but it has negligible effect. The commit merges `Engine::new_generic` into `Engine::new`. This allows the removal of various other things: `GenKillSet`, `gen_kill_statement_effects_in_block`, `is_cfg_cyclic`.
2024-10-12mark InterpResult as must_useRalf Jung-0/+1
2024-10-08coverage. Adapt to mcdc mapping formats introduced by llvm 19zhuyunxing-31/+30
2024-10-08coverage. MCDC ConditionId start from 0 to keep with llvm 19zhuyunxing-13/+3
2024-10-06various fixes for `naked_asm!` implementationFolkert de Vries-4/+28
- fix for divergence - fix error message - fix another cranelift test - fix some cranelift things - don't set the NORETURN option for naked asm - fix use of naked_asm! in doc comment - fix use of naked_asm! in run-make test - use `span_bug` in unreachable branch
2024-10-05clarify semantics of ConstantIndex MIR projectionRalf Jung-2/+4
2024-10-01Rollup merge of #130885 - RalfJung:interp-error-discard, r=oli-obkJubilee-33/+220
panic when an interpreter error gets unintentionally discarded One important invariant of Miri is that when an interpreter error is raised (*in particular* a UB error), those must not be discarded: it's not okay to just check `foo().is_err()` and then continue executing. This seems to catch new contributors by surprise fairly regularly, so this PR tries to make it so that *if* this ever happens, we get a panic rather than a silent missed UB bug. The interpreter error type now contains a "guard" that panics on drop, and that is explicitly passed to `mem::forget` when an error is deliberately discarded. Fixes https://github.com/rust-lang/miri/issues/3855
2024-10-01make InterpResult a dedicated type to avoid accidentally discarding the errorRalf Jung-88/+220
2024-10-01Replace -Z default-hidden-visibility with -Z default-visibilityDavid Lattimore-0/+11
MCP: https://github.com/rust-lang/compiler-team/issues/782 Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2024-09-30panic when an interpreter error gets unintentionally discardedRalf Jung-9/+64
2024-09-28tweak Const::identity_unevaluated name and docsRalf Jung-1/+3
2024-09-28try to get rid of mir::Const::normalizeRalf Jung-12/+0
2024-09-25Auto merge of #130803 - cuviper:file-buffered, r=joshtriplettbors-2/+2
Add `File` constructors that return files wrapped with a buffer In addition to the light convenience, these are intended to raise visibility that buffering is something you should consider when opening a file, since unbuffered I/O is a common performance footgun to Rust newcomers. ACP: https://github.com/rust-lang/libs-team/issues/446 Tracking Issue: #130804
2024-09-24Dogfood `feature(file_buffered)`Josh Stone-2/+2
2024-09-24update doc commentLukas Markeffsky-2/+4
2024-09-24be even more precise about "cast" vs "coercion"Lukas Markeffsky-5/+14
2024-09-24replace "cast" with "coercion" where applicableLukas Markeffsky-1/+3
This changes the remaining span for the cast, because the new `Cast` category has a higher priority (lower `Ord`) than the old `Coercion` category, so we no longer report the region error for the "unsizing" coercion from `*const Trait` to itself.
2024-09-24unify dyn* coercions with other pointer coercionsLukas Markeffsky-3/+0
2024-09-23Check vtable projections for validity in miriMichael Goulet-16/+19
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-34/+34
2024-09-21Compute reachable locals as part of non_ssa_localsBen Kimock-83/+41
2024-09-21Don't alloca for unused localsBen Kimock-8/+111
2024-09-14Auto merge of #128543 - RalfJung:const-interior-mut, r=fee1-deadbors-4/+43
const-eval interning: accept interior mutable pointers in final value …but keep rejecting mutable references This fixes https://github.com/rust-lang/rust/issues/121610 by no longer firing the lint when there is a pointer with interior mutability in the final value of the constant. On stable, such pointers can be created with code like: ```rust pub enum JsValue { Undefined, Object(Cell<bool>), } impl Drop for JsValue { fn drop(&mut self) {} } // This does *not* get promoted since `JsValue` has a destructor. // However, the outer scope rule applies, still giving this 'static lifetime. const UNDEFINED: &JsValue = &JsValue::Undefined; ``` It's not great to accept such values since people *might* think that it is legal to mutate them with unsafe code. (This is related to how "infectious" `UnsafeCell` is, which is a [wide open question](https://github.com/rust-lang/unsafe-code-guidelines/issues/236).) However, we [explicitly document](https://doc.rust-lang.org/reference/behavior-considered-undefined.html) that things created by `const` are immutable. Furthermore, we also accept the following even more questionable code without any lint today: ```rust let x: &'static Option<Cell<i32>> = &None; ``` This is even more questionable since it does *not* involve a `const`, and yet still puts the data into immutable memory. We could view this as promotion [potentially introducing UB](https://github.com/rust-lang/unsafe-code-guidelines/issues/493). However, we've accepted this since ~forever and it's [too late to reject this now](https://github.com/rust-lang/rust/pull/122789); the pattern is just too useful. So basically, if you think that `UnsafeCell` should be tracked fully precisely, then you should want the lint we currently emit to be removed, which this PR does. If you think `UnsafeCell` should "infect" surrounding `enum`s, the big problem is really https://github.com/rust-lang/unsafe-code-guidelines/issues/493 which does not trigger the lint -- the cases the lint triggers on are actually the "harmless" ones as there is an explicit surrounding `const` explaining why things end up being immutable. What all this goes to show is that the hard error added in https://github.com/rust-lang/rust/pull/118324 (later turned into the future-compat lint that I am now suggesting we remove) was based on some wrong assumptions, at least insofar as it concerns shared references. Furthermore, that lint does not help at all for the most problematic case here where the potential UB is completely implicit. (In fact, the lint is actively in the way of [my preferred long-term strategy](https://github.com/rust-lang/unsafe-code-guidelines/issues/493#issuecomment-2028674105) for dealing with this UB.) So I think we should go back to square one and remove that error/lint for shared references. For mutable references, it does seem to work as intended, so we can keep it. Here it serves as a safety net in case the static checks that try to contain mutable references to the inside of a const initializer are not working as intended; I therefore made the check ICE to encourage users to tell us if that safety net is triggered. Closes https://github.com/rust-lang/rust/issues/122153 by removing the lint. Cc `@rust-lang/opsem` `@rust-lang/lang`