about summary refs log tree commit diff
path: root/compiler/rustc_const_eval
AgeCommit message (Collapse)AuthorLines
2024-06-05Add `Ty` to `mir::Const::Ty`Boxy-2/+2
2024-06-05Add `Ty` to `ConstKind::Value`Boxy-1/+1
2024-06-05Update the interpreter to handle the new casesBen Kimock-9/+22
2024-06-04Add safe/unsafe to static inside extern blocksSantiago Pastorino-2/+4
2024-06-03Opt-in diagnostics reporting to avoid doing extra work in the new solverMichael Goulet-1/+1
2024-06-03Auto merge of #125778 - estebank:issue-67100, r=compiler-errorsbors-1/+1
Use parenthetical notation for `Fn` traits Always use the `Fn(T) -> R` format when printing closure traits instead of `Fn<(T,), Output = R>`. Address #67100: ``` error[E0277]: expected a `Fn()` closure, found `F` --> file.rs:6:13 | 6 | call_fn(f) | ------- ^ expected an `Fn()` closure, found `F` | | | required by a bound introduced by this call | = note: wrap the `F` in a closure with no arguments: `|| { /* code */ }` note: required by a bound in `call_fn` --> file.rs:1:15 | 1 | fn call_fn<F: Fn() -> ()>(f: &F) { | ^^^^^^^^^^ required by this bound in `call_fn` help: consider further restricting this bound | 5 | fn call_any<F: std::any::Any + Fn()>(f: &F) { | ++++++ ```
2024-06-01Uplift TypeRelation and RelateMichael Goulet-1/+1
2024-05-29Use parenthetical notation for `Fn` traitsEsteban Küber-1/+1
Always use the `Fn(T) -> R` format when printing closure traits instead of `Fn<(T,), Output = R>`. Fix #67100: ``` error[E0277]: expected a `Fn()` closure, found `F` --> file.rs:6:13 | 6 | call_fn(f) | ------- ^ expected an `Fn()` closure, found `F` | | | required by a bound introduced by this call | = note: wrap the `F` in a closure with no arguments: `|| { /* code */ }` note: required by a bound in `call_fn` --> file.rs:1:15 | 1 | fn call_fn<F: Fn() -> ()>(f: &F) { | ^^^^^^^^^^ required by this bound in `call_fn` help: consider further restricting this bound | 5 | fn call_any<F: std::any::Any + Fn()>(f: &F) { | ++++++ ```
2024-05-29Rollup merge of #125633 - RalfJung:miri-no-copy, r=saethlin许杰友 Jieyou Xu (Joe)-26/+52
miri: avoid making a full copy of all new allocations Hopefully fixes https://github.com/rust-lang/miri/issues/3637 r? ``@saethlin``
2024-05-28Add an intrinsic for `ptr::metadata`Scott McMurray-5/+25
2024-05-28Create const block DefIds in typeck instead of ast loweringOli Scherer-1/+1
2024-05-28Remove a CTFE check that was only ever used to ICEOli Scherer-13/+1
The guarded call will ICE on its own. While this improved diagnostics in the presence of bugs somewhat, it is also a blocker to query feeding of constants. If this case is hit again, we should instead improve diagnostics of the root ICE
2024-05-27miri: avoid making a full copy of all new allocationsRalf Jung-26/+52
2024-05-27interpret: get rid of 'mir lifetime everywhereRalf Jung-255/+220
2024-05-27interpret: the MIR is actually at lifetime 'tcxRalf Jung-51/+46
2024-02-20Stabilize `LazyCell` and `LazyLock` (`lazy_cell`)Peter Jaszkowiak-1/+1
2024-05-24Rollup merge of #125483 - ↵Matthias Krüger-1409/+1
workingjubilee:move-transform-validate-to-mir-transform, r=oli-obk compiler: validate.rs belongs next to what it validates It's hard to find code that is deeply nested and far away from its callsites, so let's move `rustc_const_eval::transform::validate` into `rustc_mir_transform`, where all of its callers are. As `rustc_mir_transform` already depends on `rustc_const_eval`, the added visible dependency edge doesn't mean the dependency tree got any worse. This also lets us unnest the `check_consts` module. I did look into moving everything inside `rustc_const_eval::transform` into `rustc_mir_transform`. It turned out to be a much more complex operation, with more concerns and real edges into the `const_eval` crate, whereas this was both faster and more obvious.
2024-05-24compiler: unnest rustc_const_eval::check_constsJubilee Young-2/+1
2024-05-24compiler: const_eval/transform/validate.rs -> mir_transform/validate.rsJubilee Young-1407/+0
2024-05-24Rollup merge of #125477 - nnethercote:missed-rustfmt, r=compiler-errorsMatthias Krüger-4/+3
Run rustfmt on files that need it. Somehow these files aren't properly formatted. By default `x fmt` and `x tidy` only check files that have changed against master, so if an ill-formatted file somehow slips in it can stay that way as long as it doesn't get modified(?) I found these when I ran `x fmt` explicitly on every `.rs` file in the repo, while working on https://github.com/rust-lang/compiler-team/issues/750.
2024-05-24Auto merge of #125479 - scottmcm:validate-vtable-projections, r=Nilstriebbors-0/+9
Validate the special layout restriction on `DynMetadata` If you look at <https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/std/ptr/struct.DynMetadata.html>, you'd think that `DynMetadata` is a struct with fields. But it's actually not, because the lang item is special-cased in rustc_middle layout: https://github.com/rust-lang/rust/blob/7601adcc764d42c9f2984082b49948af652df986/compiler/rustc_middle/src/ty/layout.rs#L861-L864 That explains the very confusing codegen ICEs I was getting in https://github.com/rust-lang/rust/pull/124251#issuecomment-2128543265 > Tried to extract_field 0 from primitive OperandRef(Immediate((ptr: %5 = load ptr, ptr %4, align 8, !nonnull !3, !align !5, !noundef !3)) @ TyAndLayout { ty: DynMetadata<dyn Callsite>, layout: Layout { size: Size(8 bytes), align: AbiAndPrefAlign { abi: Align(8 bytes), pref: Align(8 bytes) }, abi: Scalar(Initialized { value: Pointer(AddressSpace(0)), valid_range: 1..=18446744073709551615 }), fields: Primitive, largest_niche: Some(Niche { offset: Size(0 bytes), value: Pointer(AddressSpace(0)), valid_range: 1..=18446744073709551615 }), variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(8 bytes) } }) because there was a `Field` projection despite the layout clearly saying it's [`Primitive`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/abi/enum.FieldsShape.html#variant.Primitive). Thus this PR updates the MIR validator to check for such a projection, and changes `libcore` to not ever emit any projections into `DynMetadata`, just to transmute the whole thing when it wants a pointer.
2024-05-23Validate the special layout restriction on DynMetadataScott McMurray-0/+9
2024-05-24Run rustfmt on files that need it.Nicholas Nethercote-4/+3
Somehow these files aren't properly formatted. By default `x fmt` and `x tidy` only check files that have changed against master, so if an ill-formatted file somehow slips in it can stay that way as long as it doesn't get modified(?) I found these when I ran `x fmt` explicitly on every `.rs` file in the repo, while working on https://github.com/rust-lang/compiler-team/issues/750.
2024-05-23Auto merge of #125434 - nnethercote:rm-more-extern-tracing, r=jackh726bors-3/+29
Remove more `#[macro_use] extern crate tracing` Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. Continuing the work from #124511 and #124914. r? `@jackh726`
2024-05-23Allow const eval failures if the cause is a type layout issueOli Scherer-7/+19
2024-05-23Remove `#[macro_use] extern crate tracing` from `rustc_const_eval`.Nicholas Nethercote-3/+29
2024-05-23Auto merge of #125359 - RalfJung:interpret-overflowing-ops, r=oli-obkbors-194/+148
interpret: make overflowing binops just normal binops Follow-up to https://github.com/rust-lang/rust/pull/125173 (Cc `@scottmcm)`
2024-05-22Auto merge of #117329 - RalfJung:offset-by-zero, r=oli-obk,scottmcmbors-27/+45
offset: allow zero-byte offset on arbitrary pointers As per prior `@rust-lang/opsem` [discussion](https://github.com/rust-lang/opsem-team/issues/10) and [FCP](https://github.com/rust-lang/unsafe-code-guidelines/issues/472#issuecomment-1793409130): - Zero-sized reads and writes are allowed on all sufficiently aligned pointers, including the null pointer - Inbounds-offset-by-zero is allowed on all pointers, including the null pointer - `offset_from` on two pointers derived from the same allocation is always allowed when they have the same address This removes surprising UB (in particular, even C++ allows "nullptr + 0", which we currently disallow), and it brings us one step closer to an important theoretical property for our semantics ("provenance monotonicity": if operations are valid on bytes without provenance, then adding provenance can't make them invalid). The minimum LLVM we require (v17) includes https://reviews.llvm.org/D154051, so we can finally implement this. The `offset_from` change is needed to maintain the equivalence with `offset`: if `let ptr2 = ptr1.offset(N)` is well-defined, then `ptr2.offset_from(ptr1)` should be well-defined and return N. Now consider the case where N is 0 and `ptr1` dangles: we want to still allow offset_from here. I think we should change offset_from further, but that's a separate discussion. Fixes https://github.com/rust-lang/rust/issues/65108 [Tracking issue](https://github.com/rust-lang/rust/issues/117945) | [T-lang summary](https://github.com/rust-lang/rust/pull/117329#issuecomment-1951981106) Cc `@nikic`
2024-05-22clarify commentRalf Jung-1/+3
Co-authored-by: scottmcm <scottmcm@users.noreply.github.com>
2024-05-21improve comment wordingRalf Jung-1/+2
2024-05-21interpret: make overflowing binops just normal binopsRalf Jung-193/+145
2024-05-21Remove erroneous comment.Nicholas Nethercote-6/+0
The comment was originally in `src/librustc_mir/lib.rs`, but now that it's in `compiler/rustc_const_eval/src/lib.rs` it's no longer appropriate.
2024-05-20Rollup merge of #125173 - scottmcm:never-checked, r=davidtwcoMatthias Krüger-42/+15
Remove `Rvalue::CheckedBinaryOp` Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996> cc `@RalfJung` While it's a draft, r? ghost
2024-05-17Remove `Rvalue::CheckedBinaryOp`Scott McMurray-42/+15
2024-05-17Rename Unsafe to SafetySantiago Pastorino-2/+2
2024-05-13offset, offset_from: allow zero-byte offset on arbitrary pointersRalf Jung-27/+44
2024-05-13Remove `extern crate rustc_middle` from `rustc_const_eval`.Nicholas Nethercote-37/+74
This requires exporting the interpreter macros so they can be used with `use crate::interpret::*`.
2024-05-11Consolidate obligation cause codes for where clausesMichael Goulet-2/+2
2024-05-10Auto merge of #124982 - compiler-errors:uplift-trait-ref, r=lcnrbors-1/+1
Uplift `TraitRef` into `rustc_type_ir` Emotional rollercoaster r? lcnr
2024-05-10Lift `TraitRef` into `rustc_type_ir`Michael Goulet-1/+1
2024-05-10Auto merge of #124952 - compiler-errors:no-error, r=lcnrbors-1/+1
Rename some `FulfillmentErrorCode`/`ObligationCauseCode` variants to be less redundant 1. Rename some `FulfillmentErrorCode` variants. 2. Always use `ObligationCauseCode::` to prefix a code, rather than using a glob import and naming them through `traits::`. 3. Rename some `ObligationCauseCode` variants -- I wasn't particularly thorough with thinking of a new names for these, so could workshop them if necessary. 4. Misc stuff from renaming. r? lcnr
2024-05-10Name tweaksMichael Goulet-1/+1
2024-05-10Rename some ObligationCauseCode variantsMichael Goulet-1/+1
2024-05-10Rollup merge of #124957 - compiler-errors:builtin-deref, r=michaelwoeristerMatthias Krüger-9/+9
Make `Ty::builtin_deref` just return a `Ty` Nowhere in the compiler are we using the mutability part of the `TyAndMut` that we used to return.
2024-05-09Make builtin_deref just return a TyMichael Goulet-9/+9
2024-05-09interpret/miri: better errors on failing offset_fromRalf Jung-20/+24
2024-05-07replace another Option<Span> by DUMMY_SPRalf Jung-10/+10
2024-05-04Rollup merge of #124720 - RalfJung:interpret-drop, r=compiler-errorsMatthias Krüger-6/+9
interpret: Drop: always evaluate place That way we can also avoid dealing with `instantiate_from_frame_and_normalize_erasing_regions`.
2024-05-04some comments or dynamic drop handlingRalf Jung-0/+6
2024-05-04interpret: Drop: always evaluate placeRalf Jung-6/+3