about summary refs log tree commit diff
path: root/compiler/rustc_mir/src
AgeCommit message (Collapse)AuthorLines
2020-12-26Constify intrinsics::copy[_nonoverlapping]Albin Hedman-0/+23
2020-12-25Auto merge of #80235 - RalfJung:validate-promoteds, r=oli-obkbors-27/+25
validate promoteds Turn on const-value validation for promoteds. This is made possible now that https://github.com/rust-lang/rust/issues/67534 is resolved. I don't think this is a breaking change. We don't promote any unsafe operation any more (since https://github.com/rust-lang/rust/pull/77526 landed). We *do* promote `const fn` calls under some circumstances (in `const`/`static` initializers), but union field access and similar operations are not allowed in `const fn`. So now is a perfect time to add this check. :D r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/67465
2020-12-25Auto merge of #80364 - Dylan-DPC:rollup-0y96okz, r=Dylan-DPCbors-12/+18
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-25Rollup merge of #80330 - eltociear:patch-2, r=lcnrDylan DPC-1/+1
Fix typo in simplify_try.rs assigment -> assignment
2020-12-25Rollup merge of #79999 - hencrice:yenlinc/79799, r=oli-obkDylan DPC-11/+17
Refactored verbose print into a function Also handle Tuple and Array separately, which was not explicitly checked. Fixes #79799.
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-24Auto merge of #77692 - PankajChaudhary5:issue-76630, r=davidtwcobors-3/+4
Added better error message for shared borrow treated as unique for purposes of lifetimes Part of Issue #76630 r? `@jyn514`
2020-12-23Fixed formattingYenlin Chen-3/+1
2020-12-23Addressed feedbacksYenlin Chen-17/+3
Also updated the mir-opt test output files.
2020-12-23Fix typo in simplify_try.rsIkko Ashimine-1/+1
assigment -> assignment
2020-12-21Auto merge of #79270 - RalfJung:array-repeat-consts, r=oli-obkbors-37/+41
Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749, accidentally, the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec<i32> = Vec::new(); pub const fn bar() -> [Vec<i32>; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast, if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY,).0`), this would have failed. We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)), so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved). Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]`, or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor, it should run in the former case (but currently doesn't, due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the `let`-expansion does *not* work in general, for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147
2020-12-21Rollup merge of #80199 - RalfJung:const-fake, r=oli-obkDylan DPC-6/+5
also const-check FakeRead We need to const-check all statements, including `FakeRead`, to avoid issues like https://github.com/rust-lang/rust/issues/77694. Fixes https://github.com/rust-lang/rust/issues/77694. r? ``@oli-obk``
2020-12-20promoteds in statics may refer to staticsRalf Jung-10/+18
2020-12-20validate promotedsRalf Jung-19/+9
2020-12-20use exhaustive match for checking Rvalue::RepeatRalf Jung-37/+41
2020-12-20Auto merge of #80163 - jackh726:binder-refactor-part-3, r=lcnrbors-8/+8
Make BoundRegion have a kind of BoungRegionKind Split from #76814 Also includes making `replace_escaping_bound_vars` only return `T` Going to r? `@lcnr` Feel free to reassign
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-19Rollup merge of #80133 - Aaron1011:fix/const-mut-deref, r=estebankYuki Okushi-3/+5
Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhere Fixes #79971
2020-12-18Make BoundRegion have a kind of BoungRegionKindJack Huey-8/+8
2020-12-18Switch compiler/ to intra-doc linksJoshua Nelson-1/+1
rustc_lint and rustc_lint_defs weren't switched because they're included in the compiler book and so can't use intra-doc links.
2020-12-18Rollup merge of #78164 - Aaron1011:fix/async-region-name, r=tmandryDylan DPC-1/+17
Prefer regions with an `external_name` in `approx_universal_upper_bound` Fixes #75785 When displaying a MIR borrowcheck error, we may need to find an upper bound for a region, which gives us a region to point to in the error message. However, a region might outlive multiple distinct universal regions, in which case the only upper bound is 'static To try to display a meaningful error message, we compute an 'approximate' upper bound by picking one of the universal regions. Currently, we pick the region with the lowest index - however, this caused us to produce a suboptimal error message in issue #75785 This PR `approx_universal_upper_bound` to prefer regions with an `external_name`. This causes us to prefer regions from function arguments/upvars, which seems to lead to a nicer error message in some cases.
2020-12-17Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhereAaron Hill-3/+5
Fixes #79971
2020-12-17Prefer regions with an `external_name` in `approx_universal_upper_bound`Aaron Hill-1/+17
Fixes #75785 When displaying a MIR borrowcheck error, we may need to find an upper bound for a region, which gives us a region to point to in the error message. However, a region might outlive multiple distinct universal regions, in which case the only upper bound is 'static To try to display a meaningful error message, we compute an 'approximate' upper bound by picking one of the universal regions. Currently, we pick the region with the lowest index - however, this caused us to produce a suboptimal error message in issue #75785 This PR `approx_universal_upper_bound` to prefer regions with an `external_name`. This causes us to prefer regions from function arguments/upvars, which seems to lead to a nicer error message in some cases.
2020-12-17Auto merge of #79945 - jackh726:existential_trait_ref, r=nikomatsakisbors-1/+1
Move binder for dyn to each list item This essentially changes `ty::Binder<&'tcx List<ExistentialTraitRef>>` to `&'tcx List<ty::Binder<ExistentialTraitRef>>`. This is a first step in moving the `dyn Trait` representation closer to Chalk, which we've talked about in `@rust-lang/wg-traits.` r? `@nikomatsakis`
2020-12-17Auto merge of #80114 - GuillaumeGomez:rollup-gszr5kn, r=GuillaumeGomezbors-24/+9
Rollup of 5 pull requests Successful merges: - #80006 (BTreeMap: more expressive local variables in merge) - #80022 (BTreeSet: simplify implementation of pop_first/pop_last) - #80035 (Optimization for bool's PartialOrd impl) - #80040 (Always run intrinsics lowering pass) - #80047 (Use more symbols in rustdoc) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2020-12-17Rollup merge of #80040 - tmiasko:always-lower-intrinsics, r=Dylan-DPCGuillaume Gomez-24/+9
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-17Auto merge of #79840 - dvtkrlbs:issue-79667, r=oli-obkbors-68/+17
Remove memoization leftovers from constant evaluation machine Closes #79667
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-15Auto merge of #78399 - vn-ki:gsgdt-graphviz, r=oli-obkbors-133/+89
make MIR graphviz generation use gsgdt gsgdt [https://crates.io/crates/gsgdt] is a crate which provides an interface for stringly typed graphs. It also provides generation of graphviz dot format from said graph. This is the first in a series of PRs on moving graphviz code out of rustc into normal crates and then implementating graph diffing on top of these crates. r? `@oli-obk`
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-28/+147
[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-24/+9
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-13Refactored verbose print into a functionYenlin Chen-11/+33
Also handle Tuple and Array separately, which was not explicitly checked. Fixes #79799.
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-13Rollup merge of #79942 - JCTyblaidd:static-mem-init, r=RalfJungYuki Okushi-5/+14
Add post-init hook for static memory for miri. Adds a post-initialization hook to treat memory initialized using the interpreter as if it was initialized in a static context. See: https://github.com/rust-lang/miri/pull/1644 & https://github.com/rust-lang/miri/issues/1643
2020-12-13Rollup merge of #79940 - matthiaskrgr:cl15ppy, r=Dylan-DPCYuki Okushi-5/+6
fix more clippy::complexity findings fix clippy::unnecessary_filter_map use if let Some(x) = .. instead of ...map(|x|) to conditionally run fns that return () (clippy::option_map_unit_fn) fix clippy::{needless_bool, manual_unwrap_or} don't clone types that are copy (clippy::clone_on_copy) don't convert types into identical types with .into() (clippy::useless_conversion) use strip_prefix over slicing (clippy::manual_strip) r? ``@Dylan-DPC``
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-12Auto merge of #79931 - RalfJung:no-redundant-storage-live, r=oli-obkbors-23/+16
make redundant StorageLive UB The interesting behavior of StorageLive in loops (https://github.com/rust-lang/rust/issues/42371) has been fixed, so we can now finally make it a hard error to mark a local as live that is already live. :) r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/42371
2020-12-12Auto merge of #79553 - sexxi-goose:mir_min_cap_writeback, r=nikomatsakisbors-8/+14
Capture precise paths in THIR and MIR This PR allows THIR and MIR to use the result of the new capture analysis to actually capture precise paths To achieve we: - Writeback min capture results to TypeckResults - Move handling upvars to PlaceBuilder in mir_build - Lower precise paths in THIR build by reading min_captures - Search for ancestors in min_capture when trying to build a MIR place which starts off of an upvar Closes: https://github.com/rust-lang/project-rfc-2229/issues/10 Partly implements: rust-lang/project-rfc-2229#18 Work that remains (not in this PR): - [ ] [Known bugs when feature gate is enabled](https://github.com/rust-lang/project-rfc-2229/projects/1?card_filter_query=label%3Abug) - [ ] Use min_capure_map for - [ ] Liveness analysis - [ ] rustc_mir/interpret/validity.rs - [ ] regionck - [ ] rust-lang/project-rfc-2229#8 - [ ] remove closure_captures and upvar_capture_map r? `@ghost`
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-04 10:49:02 +0000