about summary refs log tree commit diff
path: root/compiler/rustc_middle/src/mir/interpret
AgeCommit message (Collapse)AuthorLines
2023-11-26rustc: `hir().local_def_id_to_hir_id()` -> `tcx.local_def_id_to_hir_id()` ↵Vadim Petrochenkov-1/+1
cleanup
2023-11-19Expand Miri's BorTag GC to a Provenance GCBen Kimock-7/+0
2023-11-16Let Miri see the AllocId for all TyCtxt allocationsBen Kimock-0/+7
2023-10-16Auto merge of #114330 - RalfJung:dagling-ptr-deref, r=oli-obkbors-10/+25
don't UB on dangling ptr deref, instead check inbounds on projections This implements https://github.com/rust-lang/reference/pull/1387 in Miri. See that PR for what the change is about. Detecting dangling references in `let x = &...;` is now done by validity checking only, so some tests need to have validity checking enabled. There is no longer inherently a "nodangle" check in evaluating the expression `&*ptr` (aside from the aliasing model). r? `@oli-obk` Based on: - https://github.com/rust-lang/reference/pull/1387 - https://github.com/rust-lang/rust/pull/115524
2023-10-16Auto merge of #116724 - RalfJung:alloc-bytes, r=oli-obkbors-13/+5
interpret: clean up AllocBytes Fixes https://github.com/rust-lang/miri/issues/2836 Nothing has moved here in half a year, so let's just remove these unused stubs -- they need a proper re-design anyway. r? `@oli-obk`
2023-10-15more precise error for 'based on misaligned pointer' caseRalf Jung-8/+18
2023-10-15place evaluation: require the original pointer to be aligned if an access ↵Ralf Jung-2/+9
happens
2023-10-15don't UB on dangling ptr deref, instead check inbounds on projectionsRalf Jung-2/+0
2023-10-14interpret: clean up AllocBytesRalf Jung-13/+5
2023-10-13Format all the let chains in compilerMichael Goulet-1/+3
2023-09-30dont call mir.post_mono_checks in codegenRalf Jung-15/+0
2023-09-20Auto merge of #115827 - eduardosm:miri-sse-reduce-code-dup, r=RalfJungbors-4/+18
miri: reduce code duplication in some SSE/SSE2 intrinsics Reduces code duplication in the Miri implementation of some SSE and SSE2 using generics and rustc_const_eval helper functions. There are also some other minor changes. r? `@RalfJung`
2023-09-19move ConstValue into mirRalf Jung-159/+5
this way we have mir::ConstValue and ty::ValTree as reasonably parallel
2023-09-18Auto merge of #115748 - RalfJung:post-mono, r=oli-obkbors-17/+63
move required_consts check to general post-mono-check function This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants. Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) https://github.com/rust-lang/rust/issues/115709: ensuring that all locals are dynamically sized. I didn't expect this to change diagnostics, but it's just cycle errors that change. r? `@oli-obk`
2023-09-18Remove more unused `Lift` impls.Nicholas Nethercote-1/+1
2023-09-18Remove unused `Lift` derives.Nicholas Nethercote-1/+1
I found these by commenting out all `Lift` derives and then adding back the ones that were necessary to successfully compile.
2023-09-16miri: reduce code duplication in SSE/SSE2 bin_op_* functionsEduardo Sánchez Muñoz-4/+8
2023-09-14don't point at const usage site for resolution-time errorsRalf Jung-13/+40
also share the code that emits the actual error
2023-09-14move required_consts check to general post-mono-check functionRalf Jung-8/+27
2023-09-14fix clippy (and MIR printing) handling of ConstValue::Indirect slicesRalf Jung-1/+52
2023-09-14don't force all slice-typed ConstValue to be ConstValue::SliceRalf Jung-18/+7
2023-09-14make it more clear which functions create fresh AllocIdRalf Jung-7/+8
2023-09-14cleanup op_to_const a bit; rename ConstValue::ByRef → IndirectRalf Jung-6/+8
2023-09-14use AllocId instead of Allocation in ConstValue::ByRefRalf Jung-3/+7
2023-09-13rustc_middle: add `Scalar::from_i8` and `Scalar::from_i16` and use them in MiriEduardo Sánchez Muñoz-0/+10
2023-09-13make the eval() functions on our const types return the resulting valueRalf Jung-0/+2
2023-09-09give extra context to ABI mismatch errorsRalf Jung-7/+12
2023-09-04interpret: make MemPlace, Place, Operand types private to the interpreterRalf Jung-1/+1
2023-08-30move marking-locals-live out of push_stack_frame, so it happens with ↵Ralf Jung-0/+2
argument passing this entirely avoids even creating unsized locals in Immediate::Uninitialized state
2023-08-09Rollup merge of #114587 - ouz-a:smir_allocation, r=oli-obkMatthias Krüger-0/+3
Convert Const to Allocation in smir Continuation of previous pr https://github.com/rust-lang/rust/pull/114466 cc https://github.com/rust-lang/project-stable-mir/issues/15 r? `@oli-obk`
2023-08-09Convert Const to Allocation in smirouz-a-0/+3
2023-08-08interpret: remove incomplete protection against invalid where clausesRalf Jung-2/+0
2023-08-03Rollup merge of #114372 - RalfJung:const-pointer-as-int, r=oli-obkMatthias Krüger-60/+77
const validation: point at where we found a pointer but expected an integer Instead of validation just printing "unable to turn pointer into bytes", make this a regular validation error that says where in the value the bad pointer was found. Also distinguish "expected integer, got pointer" from "expected pointer, got partial pointer or mix of pointers". To avoid duplicating things too much I refactored the diagnostics for validity a bit, so that "got uninit, expected X" and "got pointer, expected X" can share the "X" part. Also all the errors emitted for validation are now grouped under `const_eval_validation` so that they are in a single group in the ftl file. r? `@oli-obk`
2023-08-03Rollup merge of #114363 - RalfJung:interpret-not-miri, r=jackh726Matthias Krüger-2/+2
avoid 'miri' when refering to the shared interpreter This is basically the rustc source code version of https://github.com/rust-lang/rustc-dev-guide/pull/1471.
2023-08-02const validation: point at where we found a pointer but expected an integerRalf Jung-60/+77
2023-08-02avoid 'miri' when refering to the shared interpreterRalf Jung-2/+2
2023-08-01properly track why we checked whether a pointer is in-boundsRalf Jung-2/+2
also simplify the in-bounds checking in Miri's borrow trackers
2023-07-30inline format!() args up to and including rustc_middleMatthias Krüger-13/+9
2023-07-27Remove `constness` from `ParamEnv`Deadbeef-7/+2
2023-07-25Auto merge of #113393 - compiler-errors:next-solver-unsize-rhs, r=lcnrbors-3/+1
Normalize the RHS of an `Unsize` goal in the new solver `Unsize` goals are... tricky. Not only do they structurally match on their self type, but they're also structural on their other type parameter. I'm pretty certain that it is both incomplete and also just plain undesirable to not consider normalizing the RHS of an unsize goal. More practically, I'd like for this code to work: ```rust trait A {} trait B: A {} impl A for usize {} impl B for usize {} trait Mirror { type Assoc: ?Sized; } impl<T: ?Sized> Mirror for T { type Assoc = T; } fn main() { // usize: Unsize<dyn B> let x = Box::new(1usize) as Box<<dyn B as Mirror>::Assoc>; // dyn A: Unsize<dyn B> let y = x as Box<<dyn A as Mirror>::Assoc>; } ``` --- In order to achieve this, we add `EvalCtxt::normalize_non_self_ty` (naming modulo bikeshedding), which *must* be used for all non-self type arguments that are structurally matched in candidate assembly. Currently this is only necessary for `Unsize`'s argument, but I could see future traits requiring this (hopefully rarely) in the future. It uses `repeat_while_none` to limit infinite looping, and normalizes the self type until it is no longer an alias. Also, we need to fix feature gate detection for `trait_upcasting` and `unsized_tuple_coercion` when HIR typeck has unnormalized types. We can do that by checking the `ImplSource` returned by selection, which necessitates adding a new impl source for tuple upcasting.
2023-07-25Make everything builtin!Michael Goulet-3/+1
2023-07-25add some sanity checks in write_immediate_no_validateRalf Jung-1/+9
2023-07-25interpret: refactor projection code to work on a common trait, and use that ↵Ralf Jung-2/+6
for visitors
2023-07-24interpret: support projecting into Place::Local without force_allocationRalf Jung-3/+2
2023-07-21Revert "Auto merge of #113166 - moulins:ref-niches-initial, r=oli-obk"David Tolnay-8/+23
This reverts commit 557359f92512ca88b62a602ebda291f17a953002, reversing changes made to 1e6c09a803fd543a98bfbe1624d697a55300a786.
2023-07-21CTFE: move `target_{i, u}size_{min, max)` to `rustc_abi::TargetDataLayout`Moulins-22/+8
2023-07-21support non-null pointer niches in CTFEMoulins-1/+0
2023-07-17Auto merge of #113562 - saethlin:larger-incr-comp-offset, r=nnethercotebors-2/+2
Use u64 for incr comp allocation offsets Fixes https://github.com/rust-lang/rust/issues/76037 Fixes https://github.com/rust-lang/rust/issues/95780 Fixes https://github.com/rust-lang/rust/issues/111613 These issues are all reporting ICEs caused by using `u32` to store offsets to allocations in the incremental compilation cache. This PR aims to lift that limitation by changing the offset type in question to `u64`. There are two perf runs in this PR. The first reports a regression, and the second does not. The changes are the same in both. I rebased the PR then did the second perf run because I noticed that the primary regression in it was very commonly seen in spurious regression reports. I do not know what the perf run will report when this is merged. I would not be surprised to see regression or neutral, but the cachegrind diffs for the regression point at `try_mark_previous_green` which is a common source of inexplicable regressions and I don't think should be perturbed by this PR. I'm not opposed to adding a regression test such as ```rust fn main() { println!("{}", [37; 1 << 30].len()); } ``` But that program takes 1 minute to compile and consumes 4.6 GB of memory then writes that much to disk. Is that a concerning amount of resource use for a test? r? `@nnethercote`
2023-07-14Use u64 for incr comp allocation offsetsBen Kimock-2/+2
2023-07-14refactor(rustc_middle): Substs -> GenericArgMahdi Dibaiee-13/+13
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 22:00:37 +0000