summary refs log tree commit diff
path: root/compiler/rustc_mir/src/const_eval
AgeCommit message (Collapse)AuthorLines
2021-07-28Improve comments about const panic handlingMara Bos-0/+2
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-07-28Check that const_panic_fmt is const too.Mara Bos-2/+9
2021-07-28Make const panic!("..") work in Rust 2021.Mara Bos-9/+28
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
2021-07-24get rid of NoMirFor error variantRalf Jung-15/+4
2021-07-15adjustions and cleanup to make Miri build againRalf Jung-2/+2
2021-07-14consistently treat None-tagged pointers as ints; get rid of some deprecated ↵Ralf Jung-6/+8
Scalar methods
2021-07-14CTFE/Miri engine Pointer type overhaul: make Scalar-to-Pointer conversion ↵Ralf Jung-35/+22
infallible This resolves all the problems we had around "normalizing" the representation of a Scalar in case it carries a Pointer value: we can just use Pointer if we want to have a value taht we are sure is already normalized.
2021-07-10Update testsDeadbeef-1/+1
2021-07-10Update CTFE to allow fns marked with the attrDeadbeef-6/+9
2021-07-10functions marked with attr are not constDeadbeef-3/+0
2021-07-10Treat trait fns marked with the attr as constDeadbeef-1/+4
2021-07-04Combine individual limit queries into single `limits` queryAaron Hill-2/+2
2021-07-04Query-ify global limit attribute handlingAaron Hill-3/+3
2021-07-02Allocation failure in constprop panics right awaySmitty-0/+2
2021-06-29Unwrap allocated Location at creationSmitty-5/+1
2021-06-29Support allocation failures when interperting MIRSmitty-3/+7
Note that this breaks Miri. Closes #79601
2021-06-16Move some hard error logic to InterpErrorSmitty-15/+17
2021-06-15Use better error message for hard errors in CTFESmitty-9/+4
Currently the same message is used for hard errors and soft errors. This makes hard errors use a message that indicates the reality of the situation correctly, since usage of the constant is never allowed when there was a hard error evaluating it.
2021-05-30Emit a hard error when a panic occurs during const-evalAaron Hill-52/+56
Previous, a panic during const evaluation would go through the `const_err` lint. This PR ensures that such a panic always causes compilation to fail.
2021-05-29Auto merge of #85767 - lqd:stackless_span_stacks, r=oli-obkbors-3/+15
A bit more polish on const eval errors This PR adds a bit more polish to the const eval errors: - a slight improvement to the PME messages from #85633: I mentioned there that the erroneous item's paths were dependent on the environment, and could be displayed fully qualified or not. This can obscure the items when they come from a dependency. This PR uses the pretty-printing code ensuring the items' paths are not trimmed. - whenever there are generics involved in an item where const evaluation errors out, the error message now displays the instance and its const arguments, so that we can see which instantiated item and compile-time values lead to the error. So we get this slight improvement for our beloved `stdarch` example, on nightly: ``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', /rustc/9111b8ae9793f18179a1336417618fc07a9cac85/library/core/src/../../stdarch/crates/core_arch/src/macros.rs:8:9 | ``` to this PR's: ``` error[E0080]: evaluation of `core::core_arch::macros::ValidateConstImm::<51_i32, 0_i32, 15_i32>::VALID` failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9 | ``` with this PR. Of course this is an idea from Oli, so maybe r? `@oli-obk` if they have the time.
2021-05-28Auto merge of #85546 - hyd-dev:unwind, r=RalfJungbors-3/+3
const-eval: disallow unwinding across functions that `!fn_can_unwind()` Following https://github.com/rust-lang/miri/pull/1776#discussion_r633074343, so r? `@RalfJung` This PR turns `unwind` in `StackPopCleanup::Goto` into a new enum `StackPopUnwind`, with a `NotAllowed` variant to indicate that unwinding is not allowed. This variant is chosen based on `rustc_middle::ty::layout::fn_can_unwind()` in `eval_fn_call()` when pushing the frame. A check is added in `unwind_to_block()` to report UB if unwinding happens across a `StackPopUnwind::NotAllowed` frame. Tested with Miri `HEAD` with [minor changes](https://github.com/rust-lang/miri/compare/HEAD..9cf3c7f0d86325a586fbcbf2acdc9232b861f1d8) and the rust-lang/miri#1776 branch with [these changes](https://github.com/rust-lang/miri/compare/d866c1c52f48bf562720383455b75c257bb1ad92..626638fbfe2fff34648dda29a34d59db498a6e52).
2021-05-28const eval errors: display the current item instance if there are generics ↵Rémy Rakic-3/+15
involved
2021-05-23Pass `StackPopUnwind` to `eval_fn_call()` and some other functions that are ↵hyd-dev-3/+3
called by `eval_fn_call()`
2021-05-23support creating mutable allocations from byte slicesRalf Jung-2/+3
2021-05-18CTFE core engine allocation & memory API improvemenetsRalf Jung-1/+1
- make Allocation API offset-based (no more Pointer) - make Memory API higher-level (combine checking for access and getting access into one operation)
2021-04-25remove now-unused 'is_min_const_fn'Ralf Jung-49/+0
2021-04-19fix few typosklensy-1/+1
2021-04-02Auto merge of #76881 - hameerabbasi:issue-53325, r=oli-obkbors-0/+10
Add allocation information to undefined behaviour errors. So far I'm looking on information on whether the error messages are suitable. Fixes #53325.
2021-03-31Add allocation information to undefined behaviour errors.Hameer Abbasi-0/+10
2021-03-29Only emit a discrimiant tag for enumsOli Scherer-1/+1
2021-03-16Update compiler/rustc_mir/src/const_eval/mod.rsOli Scherer-5/+4
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-03-15Explain pointer and dyn Trait handling in const_to_valtreeOli Scherer-9/+7
2021-03-15Explain how we encode enums at the encoding siteOli Scherer-3/+4
2021-03-15Explain why we do not allow const_to_valtree to read from staticsOli Scherer-1/+6
2021-03-12We won't support trait object constants in type level constants for the ↵Oli Scherer-3/+5
forseeable future
2021-03-12Intern valtree field vectorOli Scherer-3/+7
2021-03-12Implement valtreeOli Scherer-2/+90
valtree is a version of constants that is inherently safe to be used within types. This is in contrast to ty::Const which can have different representations of the same value. These representation differences can show up in hashing or equality comparisons, breaking type equality of otherwise equal types. valtrees do not have this problem.
2021-02-25fix reviewklensy-1/+1
2021-02-24replaced some map_or with map_or_elseklensy-1/+1
2021-02-20Auto merge of #82124 - tmiasko:op-ty-ref, r=oli-obkbors-27/+27
Pass large interpreter types by reference, not value r? `@ghost`
2021-02-17Reduce size of InterpErrorInfo to 8 bytesTomasz Miąsko-4/+8
2021-02-16Pass MPlaceTy by reference not valueTomasz Miąsko-6/+6
2021-02-16Pass PlaceTy by reference not valueTomasz Miąsko-4/+4
2021-02-16Pass OpTy by reference not valueTomasz Miąsko-17/+17
2021-02-13Heat up the ICE-y error reportingEllen-1/+1
rest in peace match bool <3
2021-02-05improve error message for disallowed ptr-to-int casts in const evalJeffrey Griffin-1/+8
2021-01-24clean up some const error reporting around promotedsRalf Jung-74/+28
2021-01-13Auto merge of #79322 - jyn514:refactor-impl, r=estebankbors-1/+1
Separate out a `hir::Impl` struct This makes it possible to pass the `Impl` directly to functions, instead of having to pass each of the many fields one at a time. It also simplifies matches in many cases. See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with. r? `@petrochenkov` maybe?
2021-01-12Separate out a `hir::Impl` structJoshua Nelson-1/+1
This makes it possible to pass the `Impl` directly to functions, instead of having to pass each of the many fields one at a time. It also simplifies matches in many cases.
2021-01-12Auto merge of #78407 - oli-obk:ub_checkable_ctfe, r=RalfJung,pnkfelixbors-0/+16
Make CTFE able to check for UB... ... by not doing any optimizations on the `const fn` MIR used in CTFE. This means we duplicate all `const fn`'s MIR now, once for CTFE, once for runtime. This PR is for checking the perf effect, so we have some data when talking about https://github.com/rust-lang/const-eval/blob/master/rfcs/0000-const-ub.md To do this, we now have two queries for obtaining mir: `optimized_mir` and `mir_for_ctfe`. It is now illegal to invoke `optimized_mir` to obtain the MIR of a const/static item's initializer, an array length, an inline const expression or an enum discriminant initializer. For `const fn`, both `optimized_mir` and `mir_for_ctfe` work, the former returning the MIR that LLVM should use if the function is called at runtime. Similarly it is illegal to invoke `mir_for_ctfe` on regular functions. This is all checked via appropriate assertions and I don't think it is easy to get wrong, as there should be no `mir_for_ctfe` calls outside the const evaluator or metadata encoding. Almost all rustc devs should keep using `optimized_mir` (or `instance_mir` for that matter).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-24 19:55:56 +0000