about summary refs log tree commit diff
path: root/src/librustc_middle/mir
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-9424/+0
2020-08-29New pass to optimize `if`conditions on integrals to switches on the integerSimon Vandel Sillesen-0/+23
Fixes #75144
2020-08-23 change offset from u32 to u64DPC-7/+7
2020-08-22MIR call terminator represents diverging calls tooSimonas Kazlauskas-1/+1
2020-08-21Suppress "const" prefix of FnDef in MIR dumpLzu Tao-1/+4
2020-08-20Auto merge of #75747 - cuviper:rollup-icke90l, r=cuviperbors-0/+11
Rollup of 8 pull requests Successful merges: - #75672 (Move to intra-doc links for task.rs and vec.rs) - #75702 (Clean up E0759 explanation) - #75703 (Enable stack-overflow detection on musl for non-main threads) - #75710 (Fix bad printing of const-eval queries) - #75716 (Upgrade Emscripten on CI to 1.39.20 ) - #75731 (Suppress ty::Float in MIR comments of ty::Const) - #75733 (Remove duplicated alloc vec bench push_all_move) - #75743 (Rename rustc_lexer::TokenKind::Not to Bang) Failed merges: r? @ghost
2020-08-20Rollup merge of #75710 - ThibsG:FixBadPrinting75447, r=oli-obkJosh Stone-0/+11
Fix bad printing of const-eval queries Fixes: #75447 r? @RalfJung cc @oli-obk
2020-08-20Auto merge of #75562 - oli-obk:const_prop_no_aggregates, r=wesleywiserbors-3/+23
Check that we don't use `Rvalue::Aggregate` after the deaggregator fixes #75481 r? @wesleywiser cc @RalfJung (modified the validator)
2020-08-20Apply suggestions from code reviewOliver Scherer-2/+2
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
2020-08-19Fix bad printing of const-eval queriesThibsG-0/+11
2020-08-18Moved coverage counter injection from BasicBlock to Statement.Rich Kadel-32/+135
2020-08-18Address review commentsOliver Scherer-1/+1
2020-08-18Validate the MIR of all optimizations in the mir-opt directoryOliver Scherer-3/+23
2020-08-17rust_ast::ast => rustc_astUjjwal Sharma-5/+5
2020-08-14Rollup merge of #75448 - lcnr:rn-as_local_hir_id, r=davidtwcoTyler Mandry-8/+9
merge `as_local_hir_id` with `local_def_id_to_hir_id` `as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing. Don't really care about which of these 2 methods we want to keep. Does this require an MCP, considering that these methods are fairly frequently used?
2020-08-14Fix tests and address review commentsMatthew Jasper-1/+1
2020-08-14Rework `rustc_serialize`Matthew Jasper-86/+85
- 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-13merge `as_local_hir_id` with `local_def_id_to_hir_id`Bastian Kauschke-8/+9
2020-08-12fix LocalInfo doc commentRalf Jung-3/+6
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-7/+52
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-7/+52
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-29Auto merge of #74733 - richkadel:llvm-coverage-map-gen-5, r=tmandrybors-4/+4
Fixed coverage map issues; better aligned with LLVM APIs Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging, I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat, resulting in less code overall, expanded coverage of LLVM Coverage Map capabilities, and much closer alignment with LLVM data structures, APIs, and naming. This should be easier to follow and easier to maintain. r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
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-25Fixed coverage map issues; better aligned with LLVM APIsRich Kadel-4/+4
Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging, I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat, resulting in less code overall, expanded coverage of LLVM Coverage Map capabilities, and much closer alignment with LLVM data structures, APIs, and naming. This should be easier to follow and easier to maintain.
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-20trait_sel: only test predicates w/ no substsDavid Wood-1/+1
This commit modifies the `substitute_normalize_and_test_predicates` query, renaming it to `impossible_predicates` and only checking predicates which do not require substs. By making this change, polymorphization doesn't have to explicitly support vtables. Signed-off-by: David Wood <david@davidtw.co>
2020-07-19Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4, r=tmandrybors-9/+8
Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation, at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE="main.profraw" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-17Rollup merge of #74169 - ecstatic-morse:dataflow-unreachable, r=pnkfelixManish Goregaokar-0/+17
Stop processing unreachable blocks when solving dataflow ...instead we `debug_assert` that the user is not checking the dataflow state for an unreachable block. This resolves a FIXME in the dataflow engine. The old behavior was an artifact of the previous dataflow framework. Things should run a tiny bit faster now, but I suspect not enough to show up in benchmarks. AFAIK, only the generator transform runs dataflow on MIR with unreachable basic blocks. This PR also adds some utility methods to `mir::traversal`. r? @pnkfelix
2020-07-17Generating the coverage mapRich Kadel-9/+8
rustc now generates the coverage map and can support (limited) coverage report generation, at the function level. Example: $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE="main.profraw" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main 1| 1|pub fn will_be_called() { 2| 1| println!("called"); 3| 1|} 4| | 5| 0|pub fn will_not_be_called() { 6| 0| println!("should not have been called"); 7| 0|} 8| | 9| 1|fn main() { 10| 1| let less = 1; 11| 1| let more = 100; 12| 1| 13| 1| if less < more { 14| 1| will_be_called(); 15| 1| } else { 16| 1| will_not_be_called(); 17| 1| } 18| 1|}
2020-07-17Rename TypeckTables to TypeckResults.Valentin Lazureanu-1/+1
2020-07-17Add `UnsafetyViolationDetails`.Nicholas Nethercote-4/+88
This replaces the need for the `description` and `details` symbols in `UnsafetyViolation`, which are static. As a result some `Symbol::as_str()` calls are no longer necessary, which is nice.
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-15Auto merge of #74113 - lcnr:type-dependent-consts-2, r=eddybbors-6/+42
Support const args in type dependent paths (Take 2) once more, except it is sound this time :smiling_face_with_three_hearts: previously #71154 ----- ```rust #![feature(const_generics)] struct A; impl A { fn foo<const N: usize>(&self) -> usize { N } } struct B; impl B { fn foo<const N: usize>(&self) -> usize { 42 } } fn main() { let a = A; a.foo::<7>(); } ``` When calling `type_of` for generic const arguments, we now use the `TypeckTables` of the surrounding body to get the expected type. This alone causes cycle errors though, as we now have `typeck_tables_of(main)` -> `...` -> `type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290) To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by calling `type_of(param_def_id)` instead. We have to somehow remember the `DefId` of the param through all of typeck, which is done using the struct `ty::WithOptConstParam<DefId>`, which replaces `DefId` where needed and contains an `Option<DefId>` to be able to store the const parameter in case it exists. Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached), with `query_name_of_const_arg` taking a pair `(did, param_did): (LocalDefId, DefId)`. For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`. r? @eddyb @varkor
2020-07-15unify Instance::resolveBastian Kauschke-1/+1
2020-07-15improve namingBastian Kauschke-6/+9
2020-07-15update promoted_mirBastian Kauschke-0/+12