about summary refs log tree commit diff
path: root/compiler/rustc_mir/src
AgeCommit message (Collapse)AuthorLines
2021-03-27lazily calls some fnsklensy-1/+1
2021-03-25Auto merge of #83445 - erikdesjardins:rmunion, r=RalfJungbors-1/+33
RemoveZsts: don't touch unions This should fix a Miri ICE r? `@RalfJung`
2021-03-25Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandrybors-28/+32
coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`
2021-03-24RemoveZsts: don't touch unionsErik Desjardins-1/+33
2021-03-23Add has_default to GenericParamDefKind::Constkadmin-1/+2
This currently creates a field which is always false on GenericParamDefKind for future use when consts are permitted to have defaults Update const_generics:default locations Previously just ignored them, now actually do something about them. Fix using type check instead of value Add parsing This adds all the necessary changes to lower const-generics defaults from parsing. Change P<Expr> to AnonConst This matches the arguments passed to instantiations of const generics, and makes it specific to just anonymous constants. Attempt to fix lowering bugs
2021-03-23Auto merge of #83177 - erikdesjardins:zstassign, r=oli-obkbors-52/+86
Remove assignments to ZST places instead of marking ZST return place as unused partially reverts #83118 requested by `@tmiasko` in https://github.com/rust-lang/rust/pull/83118#issuecomment-799692574 r? `@oli-obk`
2021-03-22only run RemoveZsts at mir-opt-level 3 and aboveErik Desjardins-0/+3
2021-03-22Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakisbors-1/+1
Stabilize or_patterns (RFC 2535, 2530, 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
2021-03-22Rollup merge of #83351 - RalfJung:precise-const-drop, r=oli-obkDylan DPC-1/+7
post-drop-elab check-const: explain why we still check qualifs r? `@oli-obk`
2021-03-21post-drop-elab check-const: explain why we still check qualifsRalf Jung-1/+7
2021-03-21Rollup merge of #83327 - tmiasko:visit-lhs, r=davidtwcoDylan DPC-1/+3
Extend comment in `UsedLocals::visit_lhs`
2021-03-20update `const_eval_resolve`lcnr-2/+2
2021-03-20extract `ConstKind::Unevaluated` into a structlcnr-17/+19
2021-03-19avoid calling for types which can't be ZSTsErik Desjardins-12/+30
2021-03-19stabilize or_patternsmark-1/+1
2021-03-19coverage bug fixes and optimization supportRich Kadel-28/+32
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports.
2021-03-20Extend comment in `UsedLocals::visit_lhs`Tomasz Miąsko-1/+3
2021-03-19Rollup merge of #83277 - spastorino:early_otherwise-opt-unsound, r=oli-obkDylan DPC-0/+5
Mark early otherwise optimization unsound r? `@oli-obk` cc `@tmiasko` Related to #78496 and #82905 Should I also bump this one to level 3 or 4 or given that is unsound it doesn't matter?. Probably need to adjust some tests.
2021-03-19Auto merge of #82951 - sexxi-goose:wr-mir-replace-methods2, r=nikomatsakisbors-44/+81
Replace closures_captures and upvar_capture with closure_min_captures Removed all uses of closures_captures and upvar_capture and refactored code to work with closure_min_captures. This also involved removing functions that were no longer needed like the bridge. Closes https://github.com/rust-lang/project-rfc-2229/issues/18 r? `@nikomatsakis`
2021-03-18Replace closures_captures and upvar_capture with closure_min_capturesJennifer Wills-44/+81
make changes to liveness to use closure_min_captures use different span borrow check uses new structures rename to CapturedPlace stop using upvar_capture in regionck remove the bridge cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs remove line from livenes test make our unused var checking more consistent update tests adding more warnings to the tests move is_ancestor_or_same_capture to rustc_middle/ty update names to reflect the closures add FIXME check that all captures are immutable borrows before returning add surrounding if statement like the original move var out of the loop and rename Co-authored-by: Logan Mosier <logmosier@gmail.com> Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
2021-03-18Mark early otherwise optimization unsoundSantiago Pastorino-0/+5
2021-03-18Remove unwrap_none/expect_none from compiler/.Mara Bos-12/+19
2021-03-17remove inhabitedness checkErik Desjardins-1/+1
2021-03-17remove unnecessary and ineffective cachingErik Desjardins-22/+9
2021-03-18Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiserDylan DPC-18/+57
Make source-based code coverage compatible with MIR inlining When codegenning code coverage use the instance that coverage data was originally generated for, to ensure basic level of compatibility with MIR inlining. Fixes #83061
2021-03-16move to separate pass, cache layoutsErik Desjardins-26/+52
2021-03-16Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasperbors-110/+261
Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
2021-03-16Update compiler/rustc_mir/src/const_eval/mod.rsOli Scherer-5/+4
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-03-15remove assignments to ZST placesErik Desjardins-1/+26
2021-03-15revert changes from #83118 to mark zst return place as unusedErik Desjardins-52/+27
2021-03-15Functions inlined into reachable functions are reachableTomasz Miąsko-0/+25
Consider functions to be reachable for code coverage purposes, either when they reach the code generation directly, or indirectly as inlined part of another function.
2021-03-15Make source-based code coverage compatible with MIR inliningTomasz Miąsko-18/+32
When codegenning code coverage use the instance that coverage data was originally generated for, to ensure basic level of compatibility with MIR inlining.
2021-03-15Use tracing instrumentation for better bug diagnosingOli Scherer-8/+3
2021-03-15Explain pointer and dyn Trait handling in const_to_valtreeOli Scherer-9/+7
2021-03-15Explain how we encode enums at the encoding siteOli Scherer-3/+4
2021-03-15Explain why we do not allow const_to_valtree to read from staticsOli Scherer-1/+6
2021-03-15s/ConstantSource/ConstantKind/Oli Scherer-12/+12
2021-03-14remove unnecessary conditionErik Desjardins-3/+1
`_local` isn't visited in `_local = <rhs>` statements in the situation we care about
2021-03-13Move ZST check inside UsedLocalsSimon Vandel Sillesen-50/+53
2021-03-13Extend SimplifyLocals to remove ZST writesSimon Vandel Sillesen-3/+27
2021-03-12We won't support trait object constants in type level constants for the ↵Oli Scherer-3/+5
forseeable future
2021-03-12Prepare mir::Constant for ty::Const only supporting valtreesOli Scherer-107/+157
2021-03-12Intern valtree field vectorOli Scherer-3/+7
2021-03-12Implement valtreeOli Scherer-3/+95
valtree is a version of constants that is inherently safe to be used within types. This is in contrast to ty::Const which can have different representations of the same value. These representation differences can show up in hashing or equality comparisons, breaking type equality of otherwise equal types. valtrees do not have this problem.
2021-03-12Auto merge of #82935 - henryboisdequin:diagnostic-cleanups, r=estebankbors-6/+7
Diagnostic cleanups Follow up to #81503 Helps with #82916 (don't show note if `span` is `DUMMY_SP`)
2021-03-12Don't show note if `span` is `DUMMY_SP`Henry Boisdequin-6/+7
2021-03-10Auto merge of #82982 - Dylan-DPC:rollup-mt497z7, r=Dylan-DPCbors-3/+7
Rollup of 9 pull requests Successful merges: - #81309 (always eagerly eval consts in Relate) - #82217 (Edition-specific preludes) - #82807 (rustdoc: Remove redundant enableSearchInput function) - #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands) - #82949 (Do not attempt to unlock envlock in child process after a fork.) - #82955 (fix: wrong word) - #82962 (Treat header as first paragraph for shortened markdown descriptions) - #82976 (fix error message for copy(_nonoverlapping) overflow) - #82977 (Rename `Option::get_or_default` to `get_or_insert_default`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-03-10Rollup merge of #82977 - camsteffen:opt-get-insert-def, r=m-ou-seDylan DPC-2/+3
Rename `Option::get_or_default` to `get_or_insert_default` ...as [suggested](https://github.com/rust-lang/rust/issues/82901#issuecomment-793548515) by `@m-ou-se.` In hindsight this seems rather obvious, at least to me. r? `@joshtriplett`
2021-03-10Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi, r=Amanieubors-3/+3
Implement RFC 2945: "C-unwind" ABI ## Implement RFC 2945: "C-unwind" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages, but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`, and `Thiscall` variants, marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/`, which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function, used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort, assuming that the `panic=unwind` strategy is being used, and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
2021-03-10Rename Option::get_or_insert_defaultCameron Steffen-2/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 15:50:06 +0000