about summary refs log tree commit diff
path: root/compiler/rustc_middle/src/mir
AgeCommit message (Collapse)AuthorLines
2020-09-19Rollup merge of #76636 - RalfJung:miri-size-assert, r=oli-obkRalf Jung-0/+3
assert ScalarMaybeUninit size I noticed most low-level Miri types have such an assert but `ScalarMaybeUninit` does not, so let's add that. Good t see that the `Option`-like optimization kicks in and this is no bigger than `Scalar`. :) r? @oli-obk
2020-09-19Reflect the "do not call this query directly" mentality in its nameOliver Scherer-2/+2
2020-09-19Address review commentsOliver Scherer-4/+4
2020-09-19Unify the names of const eval queries and their return typesOliver Scherer-14/+14
2020-09-19Rename const eval queries to reflect the validation changesOliver Scherer-3/+3
2020-09-18don't take `TyCtxt` by referenceBastian Kauschke-9/+9
2020-09-18support const_evaluatable_checked across crate boundariesBastian Kauschke-1/+1
2020-09-18use newtype_index for abstract_const::NodeIdBastian Kauschke-2/+7
2020-09-18initial working stateBastian Kauschke-0/+16
2020-09-17Use relative link instead of absoluteCamelid-1/+1
2020-09-17Fix wording in mir docIvan Tham-1/+1
2020-09-16Update based on review suggestionsCamelid-2/+6
2020-09-15Improve wordingCamelid-3/+3
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-09-14Clarify how branching works in a CFGCamelid-3/+5
2020-09-14Add docs for `BasicBlock`Camelid-0/+14
2020-09-14Minor improvements to `mir::Constant` docsCamelid-2/+2
2020-09-12also assert ScalarMaybeUninit sizeRalf Jung-0/+3
2020-09-10Auto merge of #75573 - Aaron1011:feature/const-mutation-lint, r=oli-obkbors-0/+2
Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..`, this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`), including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary, the original `const` item will not be modified.
2020-09-09Rollup merge of #76523 - tmiasko:non-use-context-coverage, r=wesleywiserTyler Mandry-2/+0
Remove unused PlaceContext::NonUse(NonUseContext::Coverage) r? @richkadel / @wesleywiser
2020-09-09Remove unused PlaceContext::NonUse(NonUseContext::Coverage)Tomasz Miąsko-2/+0
2020-09-08reviewBastian Kauschke-0/+4
2020-09-08make `ConstEvaluatable` more strictBastian Kauschke-4/+23
2020-09-07Add CONST_ITEM_MUTATION lintAaron Hill-0/+2
Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..`, this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`), including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary, the original `const` item will not be modified.
2020-09-06Add peephold optimization that simplifies Ne(_1, false) and Ne(false, _1) ↵Simon Vandel Sillesen-0/+9
into _1 This was observed emitted from the MatchBranchSimplification pass.
2020-09-05Rollup merge of #76254 - tmiasko:fold-len, r=wesleywiserDylan DPC-1/+1
Fold length constant in Rvalue::Repeat Fixes #76248.
2020-09-04Fix big endian read/writeJubilee Young-6/+12
Co-authored-by: matthewjasper <mjjasper1@gmail.com>
2020-09-04Explain contract of {read, write}_target_uintJubilee Young-0/+6
2020-09-04Be explicit that we're handling bytesJubilee-1/+1
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-09-04Remove reference to byteorder limitsJubilee Young-8/+4
2020-09-04Refactor byteorder to std in rustc_middleJubilee Young-7/+9
Use std::io::{Read, Write} and {to, from}_{le, be}_bytes methods in order to remove byteorder from librustc_middle's dependency graph.
2020-09-04Change ty.kind to a methodLeSeulArtichaut-3/+3
2020-09-04Auto merge of #76004 - richkadel:llvm-coverage-map-gen-6b.5, r=tmandrybors-1/+18
Tools, tests, and experimenting with MIR-derived coverage counters Leverages the new mir_dump output file in HTML+CSS (from #76074) to visualize coverage code regions and the MIR features that they came from (including overlapping spans). See example below. The `run-make-fulldeps/instrument-coverage` test has been refactored to maximize test coverage and reduce code duplication. The new tests support testing with and without `-Clink-dead-code`, so Rust coverage can be tested on MSVC (which, currently, only works with `link-dead-code` _disabled_). New tests validate coverage region generation and coverage reports with multiple counters per function. Starting with a simple `if-else` branch tests, coverage tests for each additional syntax type can be added by simply dropping in a new Rust sample program. Includes a basic, MIR-block-based implementation of coverage injection, available via `-Zexperimental-coverage`. This implementation has known flaws and omissions, but is simple enough to validate the new tools and tests. The existing `-Zinstrument-coverage` option currently enables function-level coverage only, which at least appears to generate accurate coverage reports at that level. Experimental coverage is not accurate at this time. When branch coverage works as intended, the `-Zexperimental-coverage` option should be removed. This PR replaces the bulk of PR #75828, with the remaining parts of that PR distributed among other separate and indentpent PRs. This PR depends on two of those other PRs: #76002, #76003 and #76074 Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ![Screen-Recording-2020-08-21-at-2](https://user-images.githubusercontent.com/3827298/90972923-ff417880-e4d1-11ea-92bb-8713c6198f6d.gif) r? @tmandry FYI: @wesleywiser
2020-09-03Tools, tests, and experimenting with MIR-derived coverage countersRich Kadel-1/+18
Adds a new mir_dump output file in HTML/CSS to visualize code regions and the MIR features that they came from (including overlapping spans). See example below: Includes a basic, MIR-block-based implementation of coverage injection, available via `-Zexperimental-coverage`. This implementation has known flaws and omissions, but is simple enough to validate the new tools and tests. The existing `-Zinstrument-coverage` option currently enables function-level coverage only, which at least appears to generate accurate coverage reports at that level. Experimental coverage is not accurate at this time. When branch coverage works as intended, the `-Zexperimental-coverage` option should be removed. This PR replaces the bulk of PR #75828, with the remaining parts of that PR distributed among other separate and indentpent PRs. This PR depends on three of those other PRs: #76000, #76002, and Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ![Screen-Recording-2020-08-21-at-2](https://user-images.githubusercontent.com/3827298/90972923-ff417880-e4d1-11ea-92bb-8713c6198f6d.gif)
2020-09-02pretty: trim paths of unique symbolsDan Aloni-1/+2
If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02Fold length constant in Rvalue::RepeatTomasz Miąsko-1/+1
2020-08-31Rollup merge of #76002 - richkadel:llvm-coverage-map-gen-6b.3, r=tmandryTyler Mandry-1/+1
Fix `-Z instrument-coverage` on MSVC Found that `-C link-dead-code` (which was enabled automatically under `-Z instrument-coverage`) was causing the linking error that resulted in segmentation faults in coverage instrumented binaries. Link dead code is now disabled under MSVC, allowing `-Z instrument-coverage` to be enabled under MSVC for the first time. More details are included in Issue #76038 . Note this PR makes it possible to support `Z instrument-coverage` but does not enable instrument coverage for MSVC in existing tests. It will be enabled in another PR to follow this one (both PRs coming from original PR #75828). r? @tmandry FYI: @wesleywiser
2020-08-31Fix `-Z instrument-coverage` on MSVCRich Kadel-1/+1
Found that -C link-dead-code (which was enabled automatically under -Z instrument-coverage) was causing the linking error that resulted in segmentation faults in coverage instrumented binaries. Link dead code is now disabled under MSVC, allowing `-Z instrument-coverage` to be enabled under MSVC for the first time. More details are included in Issue #76038. (This PR was broken out from PR #75828)
2020-08-30ty: remove obsolete printerDavid Wood-25/+12
This commit removes the obsolete printer and replaces all uses of it with `FmtPrinter`. Of the replaced uses, all but one use was in `debug!` logging, two cases were notable: - `MonoItem::to_string` is used in `-Z print-mono-items` and therefore affects the output of all codegen-units tests. - `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs` with `LLVMStructCreateNamed` and that'll now get different values, but this should result in no functional change. Signed-off-by: David Wood <david@davidtw.co>
2020-08-30mv compiler to compiler/mark-0/+9424
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-14 08:43:13 +0000