about summary refs log tree commit diff
path: root/compiler/rustc_mir/src/transform
AgeCommit message (Collapse)AuthorLines
2020-12-28promotion: factor some common code into validate_refRalf Jung-57/+50
2020-12-25Auto merge of #80364 - Dylan-DPC:rollup-0y96okz, r=Dylan-DPCbors-1/+1
Rollup of 11 pull requests Successful merges: - #79213 (Stabilize `core::slice::fill`) - #79999 (Refactored verbose print into a function) - #80160 (Implemented a compiler diagnostic for move async mistake) - #80274 (Rename rustc_middle::lint::LintSource) - #80280 (Add installation commands to `x` tool README) - #80319 (Fix elided lifetimes shown as `'_` on async functions) - #80327 (Updated the match with the matches macro) - #80330 (Fix typo in simplify_try.rs) - #80340 (Don't unnecessarily override attrs for Module) - #80342 (Fix typo) - #80352 (BTreeMap: make test cases more explicit on failure) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2020-12-25Auto merge of #79762 - Swatinem:remap-doctest-coverage, r=Swatinembors-1/+5
Remap instrument-coverage line numbers in doctests This uses the `SourceMap::doctest_offset_line` method to re-map line numbers from doctests. Remapping columns is not yet done, and rustdoc still does not output the correct filename when running doctests in a workspace. Part of #79417 although I dont consider that fixed until both filenames and columns are mapped correctly. r? `@richkadel` I might jump on zulip the comming days. Still need to figure out how to properly write tests for this, and deal with other doctest issues in the meantime.
2020-12-23Fix typo in simplify_try.rsIkko Ashimine-1/+1
assigment -> assignment
2020-12-19also const-check FakeReadRalf Jung-6/+5
2020-12-19Remap instrument-coverage line numbers in doctestsArpad Borsos-1/+5
This uses the `SourceMap::doctest_offset_line` method to re-map line numbers from doctests. Remapping columns is not yet done. Part of issue #79417.
2020-12-17Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhereAaron Hill-3/+5
Fixes #79971
2020-12-17Rollup merge of #80040 - tmiasko:always-lower-intrinsics, r=Dylan-DPCGuillaume Gomez-1/+1
Always run intrinsics lowering pass Move intrinsics lowering pass from the optimization phase (where it would not run if -Zmir-opt-level=0), to the drop lowering phase where it runs unconditionally. The implementation of those intrinsics in code generation and interpreter is unnecessary. Remove it.
2020-12-17Rollup merge of #80072 - richkadel:llvm-coverage-counters-2.2.1, r=tmandryYuki Okushi-2/+2
Fixed conflict with drop elaboration and coverage See https://github.com/rust-lang/rust/issues/80045#issuecomment-745733339 Coverage statements are moved to the beginning of the BCB. This does also affect what's counted before a panic, changing some results, but I think these results may even be preferred? In any case, there are no guarantees about what's counted when a panic occurs (by design). r? `@tmandry` FYI `@wesleywiser` `@ecstatic-morse`
2020-12-17Rollup merge of #79882 - wecing:master, r=oli-obkYuki Okushi-0/+27
Fix issue #78496 EarlyOtherwiseBranch finds MIR structures like: ``` bb0: { ... _2 = discriminant(X) ... switchInt(_2) -> [1_isize: bb1, otherwise: bb3] } bb1: { ... _3 = discriminant(Y) ... switchInt(_3) -> [1_isize: bb2, otherwise: bb3] } bb2: {...} bb3: {...} ``` And transforms them into something like: ``` bb0: { ... _2 = discriminant(X) _3 = discriminant(Y) _4 = Eq(_2, _3) switchInt(_4) -> [true: bb4, otherwise: bb3] } bb2: {...} // unchanged bb3: {...} // unchanged bb4: { switchInt(_2) -> [1_isize: bb2, otherwise: bb3] } ``` But that is not always a safe thing to do -- sometimes the early `otherwise` branch is necessary so the later block could assume the value of `discriminant(X)`. I am not totally sure what's the best way to detect that, but fixing #78496 should be easy -- we just check if `X` is a sub-expression of `Y`. A more precise test might be to check if `Y` contains a `Downcast(1)` of `X`, but I think this might be good enough. Fix #78496
2020-12-15Fixed conflict with drop elaboration and coverageRich Kadel-2/+2
See https://github.com/rust-lang/rust/issues/80045#issuecomment-745733339 Coverage statements are moved to the beginning of the BCB. This does also affect what's counted before a panic, changing some results, but I think these results may even be preferred? In any case, there are no guarantees about what's counted when a panic occurs (by design).
2020-12-15Rollup merge of #79958 - richkadel:llvm-coverage-counters-2.2.0, r=tmandryGuillaume Gomez-20/+24
Fixes reported bugs in Rust Coverage Fixes: #79569 Fixes: #79566 Fixes: #79565 For the first issue (#79569), I got hit a `debug_assert!()` before encountering the reported error message (because I have `debug = true` enabled in my config.toml). The assertion showed me that some `SwitchInt`s can have more than one target pointing to the same `BasicBlock`. I had thought that was invalid, but since it seems to be possible, I'm allowing this now. I added a new test for this. ---- In the last two cases above, both tests (intentionally) fail to compile, but the `InstrumentCoverage` pass is invoked anyway. The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't encountered before. (I had assumed the `InstrumentCoverage` pass would only be invoked with MIRs from successful compilations.) I don't have test infrastructure set up to test coverage on files that fail to compile, so I didn't add a new test. r? `@tmandry` FYI: `@wesleywiser`
2020-12-15Auto merge of #78068 - RalfJung:union-safe-assign, r=nikomatsakisbors-72/+93
consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However, with https://github.com/rust-lang/rust/pull/77547, unions may also have `ManuallyDrop` fields, and their assignments are currently still unsafe. That seems unnecessary though, as assigning `ManuallyDrop` does not drop anything either, and is thus safe even for union fields. I assume this will at least require FCP.
2020-12-15Auto merge of #73210 - wesleywiser:consts_in_debuginfo, r=oli-obkbors-14/+131
[mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit, debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed, we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.
2020-12-15Auto merge of #79922 - tmiasko:lower-discriminant, r=nagisabors-0/+15
Lower `discriminant_value` intrinsic This allows const propagation to evaluate comparisons involving field-less enums using derived implementations of `PartialEq` (after inlining `eq`).
2020-12-14Convenience funcs for `some_option.unwrap_or(...)`Rich Kadel-21/+11
This ensures consistent handling of default values for options that are None if not specified on the command line.
2020-12-14Disable the constant debuginfo promotion pass by defaultWesley Wiser-1/+5
It doesn't work correctly on *-pc-windows-gnu
2020-12-15Always run intrinsics lowering passTomasz Miąsko-1/+1
Move intrinsics lowering pass from the optimization phase (where it would not run if -Zmir-opt-level=0), to the drop lowering phase where it runs unconditionally. The implementation of those intrinsics in code generation and interpreter is unnecessary. Remove it.
2020-12-14Improve warnings on incompatible options involving -Zinstrument-coverageRich Kadel-19/+21
Adds checks for: * `no_core` attribute * explicitly-enabled `legacy` symbol mangling * mir_opt_level > 1 (which enables inlining) I removed code from the `Inline` MIR pass that forcibly disabled inlining if `-Zinstrument-coverage` was set. The default `mir_opt_level` does not enable inlining anyway. But if the level is explicitly set and is greater than 1, I issue a warning. The new warnings show up in tests, which is much better for diagnosing potential option conflicts in these cases.
2020-12-13Rollup merge of #79984 - Nadrieril:remove-unused-dep, r=jyn514Yuki Okushi-3/+0
Remove an unused dependency that made `rustdoc` crash Whilst struggling with https://github.com/rust-lang/rust/issues/79980 I discovered that this dependency was unused, and that made rustdoc crash. This PR removes it.
2020-12-12Remove an unused dependency that made `rustdoc` crashNadrieril-3/+0
2020-12-11Fixes reported bugs in Rust CoverageRich Kadel-12/+24
Fixes: #79569 Fixes: #79566 Fixes: #79565 For the first issue (#79569), I got hit a `debug_assert!()` before encountering the reported error message (because I have `debug = true` enabled in my config.toml). The assertion showed me that some `SwitchInt`s can have more than one target pointing to the same `BasicBlock`. I had thought that was invalid, but since it seems to be possible, I'm allowing this now. I added a new test for this. ---- In the last two cases above, both tests (intentionally) fail to compile, but the `InstrumentCoverage` pass is invoked anyway. The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't encountered before. (I had assumed the `InstrumentCoverage` pass would only be invoked with MIRs from successful compilations.) I don't have test infrastructure set up to test coverage on files that fail to compile, so I didn't add a new test.
2020-12-11fix clippy::{needless_bool, manual_unwrap_or}Matthias Krüger-3/+4
2020-12-11don't clone types that are copy (clippy::clone_on_copy)Matthias Krüger-1/+1
2020-12-11don't convert types into identical types with .into() ↵Matthias Krüger-2/+2
(clippy::useless_conversion)
2020-12-10Rollup merge of #79809 - Eric-Arellano:split-once, r=matkladTyler Mandry-28/+34
Dogfood `str_split_once()` Part of https://github.com/rust-lang/rust/issues/74773. Beyond increased clarity, this fixes some instances of a common confusion with how `splitn(2)` behaves: the first element will always be `Some()`, regardless of the delimiter, and even if the value is empty. Given this code: ```rust fn main() { let val = "..."; let mut iter = val.splitn(2, '='); println!("Input: {:?}, first: {:?}, second: {:?}", val, iter.next(), iter.next()); } ``` We get: ``` Input: "no_delimiter", first: Some("no_delimiter"), second: None Input: "k=v", first: Some("k"), second: Some("v") Input: "=", first: Some(""), second: Some("") ``` Using `str_split_once()` makes more clear what happens when the delimiter is not found.
2020-12-11Lower `discriminant_value` intrinsicTomasz Miąsko-0/+15
This allows const propagation to evaluate comparisons involving field-less enums using derived implementations of `PartialEq` (after inlining `eq`).
2020-12-09update commentsChenguang Wang-5/+4
2020-12-09fix issue #78496Chenguang Wang-0/+28
2020-12-09Rollup merge of #79818 - richkadel:llvm-coverage-counters-2.1.0, r=tmandryTyler Mandry-27/+43
Fixes to Rust coverage Fixes: #79725 Some macros can create a situation where `fn_sig_span` and `body_span` map to different files. New documentation on coverage tests incorrectly assumed multiple test binaries could just be listed at the end of the `llvm-cov` command, but it turns out each binary needs a `--object` prefix. This PR fixes the bug and updates the documentation to correct that issue. It also fixes a few other minor issues in internal implementation comments, and adds documentation on getting coverage results for doc tests.
2020-12-09remove a hack that seems to only benefit a few very special casesRalf Jung-52/+6
2020-12-08Review feedbackEric Arellano-32/+36
* Use a match statement. * Clarify why we can't use `file_stem()`. * Error if the `:` is missing for Tidy error codes, rather than no-oping.
2020-12-07Fixes to Rust coverageRich Kadel-27/+43
Fixes: #79725 Some macros can create a situation where `fn_sig_span` and `body_span` map to different files. New documentation on coverage tests incorrectly assumed multiple test binaries could just be listed at the end of the `llvm-cov` command, but it turns out each binary needs a `--object` prefix. This PR fixes the bug and updates the documentation to correct that issue. It also fixes a few other minor issues in internal implementation comments, and adds documentation on getting coverage results for doc tests.
2020-12-07Dogfood 'str_split_once() with `compiler/`Eric Arellano-23/+25
2020-12-06[mir-opt] Allow debuginfo to be generated for a constant or a PlaceWesley Wiser-14/+127
Prior to this commit, debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed, we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.
2020-12-04Auto merge of #79686 - Dylan-DPC:rollup-leama5f, r=Dylan-DPCbors-0/+2
Rollup of 11 pull requests Successful merges: - #77686 (Render Markdown in search results) - #79541 (Doc keyword lint pass) - #79602 (Fix SGX CI) - #79611 (Use more std:: instead of core:: in docs for consistency) - #79623 (Pass around Symbols instead of Idents in doctree) - #79627 (Update cargo) - #79631 (disable a ptr equality test on Miri) - #79638 (Use `item_name` instead of pretty printing for resolving `Self` on intra-doc links) - #79646 (rustc_metadata: Remove some dead code) - #79664 (move interpret::MemoryKind::Heap to const eval) - #79678 (Fix some clippy lints) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2020-12-03Addressed feedback from 2020-12-01Rich Kadel-7/+11
Added one more test (two files) showing coverage of generics and unused functions across crates. Created and referenced new Issues, as requested. Added comments. Added a note about the possible effects of compiler options on LLVM coverage maps.
2020-12-03Combination of commitsRich Kadel-127/+117
Fixes multiple issue with counters, with simplification Includes a change to the implicit else span in ast_lowering, so coverage of the implicit else no longer spans the `then` block. Adds coverage for unused closures and async function bodies. Fixes: #78542 Adding unreachable regions for known MIR missing from coverage map Cleaned up PR commits, and removed link-dead-code requirement and tests Coverage no longer depends on Issue #76038 (`-C link-dead-code` is no longer needed or enforced, so MSVC can use the same tests as Linux and MacOS now) Restrict adding unreachable regions to covered files Improved the code that adds coverage for uncalled functions (with MIR but not-codegenned) to avoid generating coverage in files not already included in the files with covered functions. Resolved last known issue requiring --emit llvm-ir workaround Fixed bugs in how unreachable code spans were added.
2020-12-03move interpret::MemoryKind::Heap to const evalVishnunarayan K I-0/+2
2020-11-25Fixup compiler docsCamelid-12/+12
The sublist was being rendered as a code block because it was indented 4 spaces.
2020-11-23Rollup merge of #79287 - jonas-schievink:const-trait-impl, r=oli-obkJonas Schievink-4/+36
Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792, this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self, _: &S) -> bool { true } } const fn equals_self<T: PartialEq>(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection, in particular through `ParamCandidate`, and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds, candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate, to avoid ambiguities when both a const and a non-const bound is present.
2020-11-23Rollup merge of #79080 - camelid:mir-visit-debuginfo-project, r=jonas-schievinkJonas Schievink-7/+1
MIR visitor: Don't treat debuginfo field access as a use of the struct Fixes #77454. r? `@jonas-schievink`
2020-11-22Add comment and remove obsolete special caseCamelid-7/+1
2020-11-22refactor unsafety checking of placesRalf Jung-75/+84
2020-11-22const fn: allow use of trait impls from boundsJonas Schievink-4/+36
2020-11-20improve formattingRalf Jung-4/+8
2020-11-20adjust union access unsafety check logic to take into account Deref and the ↵Ralf Jung-15/+20
actual type of the assignment
2020-11-20consider assignments of union field of ManuallyDrop type safeRalf Jung-25/+28
2020-11-20Auto merge of #79192 - tmiasko:naked-noinline, r=oli-obkbors-0/+5
Never inline naked functions The `#[naked]` attribute disabled prologue / epilogue emission for the function and it is responsibility of a developer to provide them. The compiler is no position to inline such functions correctly. Disable inlining of naked functions at LLVM and MIR level. Closes #60919.
2020-11-20Never inline naked functionsTomasz Miąsko-0/+5
The `#[naked]` attribute disabled prologue / epilogue emission for the function and it is responsibility of a developer to provide them. The compiler is no position to inline such functions correctly. Disable inlining of naked functions at LLVM and MIR level.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 13:02:53 +0000