about summary refs log tree commit diff
path: root/src/librustc_middle/mir/interpret
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-3007/+0
2020-08-29New pass to optimize `if`conditions on integrals to switches on the integerSimon Vandel Sillesen-0/+10
Fixes #75144
2020-08-19Fix bad printing of const-eval queriesThibsG-0/+11
2020-08-17rust_ast::ast => rustc_astUjjwal Sharma-2/+2
2020-08-14Rework `rustc_serialize`Matthew Jasper-22/+17
- Move the type parameter from `encode` and `decode` methods to the trait. - Remove `UseSpecialized(En|De)codable` traits. - Remove blanket impls for references. - Add `RefDecodable` trait to allow deserializing to arena-allocated references safely. - Remove ability to (de)serialize HIR. - Create proc-macros `(Ty)?(En|De)codable` to help implement these new traits.
2020-08-12Rollup merge of #75394 - oli-obk:get_static, r=RalfJungYuki Okushi-0/+23
Add a function to `TyCtxt` for computing an `Allocation` for a `static` item's initializer r? @RalfJung miri-side: https://github.com/rust-lang/miri/issues/1507 split out of https://github.com/rust-lang/rust/pull/74949#discussion_r468100991 to make that PR leaner
2020-08-11Add a function to `TyCtxt` for computing an `Allocation` for a `static` ↵Oliver Scherer-0/+23
item's initializer
2020-08-11Rollup merge of #75226 - pnadon:miri-undef-uninit, r=RalfJungYuki Okushi-13/+13
Miri: Renamed "undef" to "uninit" Renamed remaining references to "undef" to "uninit" when referring to Miri. Impacted directories are: - `src/librustc_codegen_llvm/consts.rs` - `src/librustc_middle/mir/interpret/` - `src/librustc_middle/ty/print/pretty.rs` - `src/librustc_mir/` - `src/tools/clippy/clippy_lints/src/consts.rs` Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project. Related issue #71193
2020-08-09move const_eval error reporting logic into rustc_mir::const_eval::errorRalf Jung-170/+5
2020-08-08Miri: Renamed "undef" to "uninit"Philippe Nadon-13/+13
Renamed remaining references to "undef" to "uninit" when referring to Miri. Impacted directories are: - src/librustc_codegen_llvm/consts.rs - src/librustc_middle/mir/interpret/ - src/librustc_middle/ty/print/pretty.rs - src/librustc_mir/ - src/tools/clippy/clippy_lints/src/consts.rs Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project. Related issue #71193
2020-08-05Auto merge of #75037 - richkadel:llvm-coverage-map-gen-5.2, r=wesleywiserbors-0/+9
Completes support for coverage in external crates Follow-up to #74959 : The prior PR corrected for errors encountered when trying to generate the coverage map on source code inlined from external crates (including macros and generics) by avoiding adding external DefIds to the coverage map. This made it possible to generate a coverage report including external crates, but the external crate coverage was incomplete (did not include coverage for the DefIds that were eliminated. The root issue was that the coverage map was converting Span locations to source file and locations, using the SourceMap for the current crate, and this would not work for spans from external crates (compliled with a different SourceMap). The solution was to convert the Spans to filename and location during MIR generation instead, so precompiled external crates would already have the correct source code locations embedded in their MIR, when imported into another crate. @wesleywiser FYI r? @tmandry
2020-08-04Completes support for coverage in external cratesRich Kadel-0/+9
The prior PR corrected for errors encountered when trying to generate the coverage map on source code inlined from external crates (including macros and generics) by avoiding adding external DefIds to the coverage map. This made it possible to generate a coverage report including external crates, but the external crate coverage was incomplete (did not include coverage for the DefIds that were eliminated. The root issue was that the coverage map was converting Span locations to source file and locations, using the SourceMap for the current crate, and this would not work for spans from external crates (compliled with a different SourceMap). The solution was to convert the Spans to filename and location during MIR generation instead, so precompiled external crates would already have the correct source code locations embedded in their MIR, when imported into another crate.
2020-08-03Auto merge of #75055 - cjgillot:clean-cache, r=oli-obkbors-1/+1
Introduce an abstraction for EvaluationCache and SelectionCache The small duplicated code has been moved to librustc_query_system. The remaining changes are some cleanups of structural impls.
2020-08-03Use more appropriate `tls::with_*` methods in some places.Nicholas Nethercote-3/+3
2020-08-02Use Lift derive proc-macro in librustc_traits.Camille GILLOT-1/+1
2020-07-31Auto merge of #65989 - Aaron1011:fix/normalize-param-env, r=nikomatsakisbors-2/+2
Normalize all opaque types when converting ParamEnv to Reveal::All When we normalize a type using a ParamEnv with a reveal mode of RevealMode::All, we will normalize opaque types to their underlying types (e.g. `type MyOpaque = impl Foo` -> `StructThatImplsFoo`). However, the ParamEnv may still have predicates referring to the un-normalized opaque type (e.g. `<T as MyTrait<MyOpaque>>`). This can cause trait projection to fail, since a type containing normalized opaque types will not match up with the un-normalized type in the `ParamEnv`. To fix this, we now explicitly normalize all opaque types in caller_bounds of a `ParamEnv` when changing its mode to `RevealMode::All`. This ensures that all predicatse will refer to the underlying types of any opaque types involved, allowing them to be matched up properly during projection. To reflect the fact that normalization is occuring, `ParamEnv::with_reveal_all` is renamed to `ParamEnv::with_reveal_all_normalized` Fixes #65918
2020-07-27Auto merge of #74775 - RalfJung:miri-alloc-ids, r=oli-obkbors-5/+3
Miri: replace canonical_alloc_id mechanism by extern_static_alloc_id We only have to call `extern_static_alloc_id` when a `Pointer` is "imported" from the `tcx` to the machine, not on each access. Also drop the old hook for TLS handling, it is not needed any more. The Miri side of this is at https://github.com/rust-lang/miri/pull/1489. Fixes https://github.com/rust-lang/rust/issues/71194 r? @oli-obk
2020-07-26typos + fmtRalf Jung-3/+1
2020-07-26Miri: replace canonical_alloc_id mechanism by extern_static_alloc_id which ↵Ralf Jung-4/+4
is called only when a pointer is 'imported' into the machine
2020-07-25Miri: rename "undef" to "uninit"Philippe Nadon-47/+47
renamed Allocation::check_defined_and_ptr to Allocation::check_init_and_ptr renamed Allocation::check_defined_and_ptr to Allocation::check_init_and_ptr in src/librustc_middle/mir/interpret/allocation.rs renamed Allocation::is_defined and Allocation::check_defined, fixed documentation renamed Allocation::is_defined and Allocation::check_defined to is_init and check_init respectively. Fixed documentation so it correctly refers to "initialization" instead of "defined"-ness renamed Allocation::mark_definedness renamed Allocation::mark_definedness to Allocation::mark_init Renamed new_state parameter in Allocation::mark_init Renamed new_state to is_init, as the latter is more descriptive. renamed functions in AllocationDefinedness renamed AllocationDefinedness::all_bytes_undef and AllocationDefinedness::mark_compressed_undef_range to no_bytes_init and mark_compressed_init_range respectively. renamed AllocationDefinedness to InitMaskCompressed renamed Immediate::to_scalar_or_undef renamed to to_scalar_or_uninit fixed comment references to "undef" Changed comments referring to "undef" and "definedness" to "initialization" and "initialization state" in src/librustc_mir/interpret/memory.rs and src/librustc_middle/mir/interpret/allocation.rs changed references to "undef" in comments and a variable Changed some comments referring to "undef" to use "uninitialized" instead. Also changed a variable from "undef_end" to "uninit_end". All changes were made within src/librustc_middle/mir/interpret/allocation.rs. Changed more comments referring to undef Changed comments to use "uninitialized" instead of "undef" in src/librustc_middle/mir/interpret/allocation.rs.
2020-07-22renamed ScalarMaybeUninit::not_undef to check_initPhilippe Nadon-15/+15
Renamed the function ScalarMaybeUninit::not_undef to ScalarMaybeUninit::check_init in the file src/librustc_middle/mir/interpret/value.rs, to reflect changes in terminology used. Related issue rust-lang#71193
2020-07-22Normalize opaque types when converting `ParamEnv` to `Reveal::All`Aaron Hill-2/+2
Fixes #65918
2020-07-15s/try_to_usize/try_to_machine_usize/Oliver Scherer-1/+1
2020-07-15Reduce the amount of interning and `layout_of` calls in const eval.Oliver Scherer-0/+12
2020-07-15unify Instance::resolveBastian Kauschke-1/+1
2020-07-15improve namingBastian Kauschke-1/+1
2020-07-15const_eval_resolveBastian Kauschke-2/+2
2020-06-19Rollup merge of #72497 - RalfJung:tag-term, r=oli-obkRalf Jung-3/+3
tag/niche terminology cleanup The term "discriminant" was used in two ways throughout the compiler: * every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`. * that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling). After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`). This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in https://github.com/rust-lang/rust/pull/72419. (There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.) r? @eddyb
2020-06-01test miri-unleash TLS accessesRalf Jung-2/+2
2020-06-01Auto merge of #71192 - oli-obk:eager_alloc_id_canonicalization, r=wesleywiserbors-0/+4
Make TLS accesses explicit in MIR r? @rust-lang/wg-mir-opt cc @RalfJung @vakaras for miri thread locals cc @bjorn3 for cranelift fixes #70685
2020-05-30miri errors: rename InvalidDiscriminant -> InvalidTagRalf Jung-3/+3
2020-05-30Make TLS accesses explicit in MIROliver Scherer-0/+4
2020-05-30Rollup merge of #72419 - RalfJung:read-discriminant, r=oli-obk,eddybYuki Okushi-2/+2
Miri read_discriminant: return a scalar instead of raw underlying bytes r? @oli-obk @eddyb
2020-05-27Add additional checks for isize overflowJoe Richey-2/+13
We now perform the correct checks even if the pointer size differs between the host and target. Signed-off-by: Joe Richey <joerichey@google.com>
2020-05-26librustc_middle: Add function for computing unsigned absJoe Richey-8/+14
This is tricky to get right if we want to avoid panicking or wrapping. Signed-off-by: Joe Richey <joerichey@google.com>
2020-05-25Miri: refactor read_discriminant and make it return ScalarRalf Jung-2/+2
2020-05-22Rollup merge of #71610 - divergentdave:InvalidUndefBytes-range, r=RalfJungRalf Jung-19/+59
InvalidUndefBytes: Track size of undef region used This PR adds a size to `UndefinedBehaviorInfo::InvalidUndefBytes`, to keep track of how many undefined bytes in a row were accessed, and changes a few methods to pass this information through. This additional information will eventually be used in Miri to improve diagnostics for this UB error. See also rust-lang/miri#1354 for prior discussion. I expect Miri will break the next time its submodule is updated, due to this change to the `InvalidUndefBytes`. (The current commit for src/tools/miri predates rust-lang/miri#1354, and thus does not try to destructure the `InvalidUndefBytes` variant) I have a corresponding change prepared for that repository. r? @RalfJung
2020-05-15InvalidUninitBytes: Track more info about accessDavid Cook-19/+59
2020-05-12Pointer printing: do not print 0 offsetRalf Jung-10/+18
2020-05-09Rollup merge of #71508 - oli-obk:alloc_map_unlock, r=RalfJungRalf Jung-46/+70
Simplify the `tcx.alloc_map` API This PR changes all functions that require manually locking the `alloc_map` to functions on `TyCtxt` that lock the map internally. In the same step we make the `TyCtxt::alloc_map` field private. r? @RalfJung
2020-05-08Document `global_alloc`Oliver Scherer-0/+4
2020-05-08Create a convenience wrapper for `get_global_alloc(id).unwrap()`Oliver Scherer-1/+10
2020-05-08Shrink visibility of the `AllocMap` and its methodsOliver Scherer-3/+3
2020-05-08Move `unwrap_fn` and `unwrap_memory` to `GlobalAlloc`Oliver Scherer-16/+22
2020-05-08Simplify the `tcx.alloc_map` APIOliver Scherer-32/+37
2020-05-07Renamed "undef" stuff to "uninit"Hanif Bin Ariffin-65/+65
1. InvalidUndefBytes -> InvalidUninitBytes 2. ScalarMaybeUndef -> ScalarMaybeUninit 3. UndefMask -> InitMask Related issue #71193
2020-05-06properly catch invalid-drop-fn errorsRalf Jung-8/+12
2020-05-06validation: port more checks to the pattern-based macro (and give it the ↵Ralf Jung-0/+5
shorter name)
2020-05-02Rollup merge of #71738 - RalfJung:pointer-no-alloc-id, r=oli-obkRalf Jung-16/+12
remove AllocId generalization of Pointer This was only needed for the "snapshot" machinery, which is gone. r? @oli-obk
2020-05-02Rollup merge of #71712 - RalfJung:error-backtrace, r=oli-obkRalf Jung-11/+9
Miri: port error backtraces to std::backtrace No need to pull in an external dependency if libstd already includes this feature (using the same dependency internally, but... still). r? @oli-obk
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 16:45:20 +0000