summary refs log tree commit diff
path: root/compiler/rustc_mir/src/util
AgeCommit message (Collapse)AuthorLines
2020-11-07use single char patterns for split() (clippy::single_char_pattern)Matthias Krüger-1/+1
2020-11-05Adds coverage graphvizRich Kadel-0/+186
2020-11-05Rust coverage before splitting instrument_coverage.rsRich Kadel-1/+3
2020-11-04s/Scalar::Raw/Scalar::Intoli-1/+1
2020-10-30Remove implicit `Continue` typeLeSeulArtichaut-1/+1
2020-10-30TypeVisitor: use `ControlFlow` in rustc_{mir,privacy,traits,typeck}LeSeulArtichaut-1/+2
2020-10-21rustc_mir: support MIR-inlining #[track_caller] functions.Eduard-Mihai Burtescu-5/+18
2020-10-21rustc_mir: track inlined callees in SourceScopeData.Eduard-Mihai Burtescu-2/+17
2020-10-17Remove the old copy propagation passJonas Schievink-159/+0
2020-10-11Use SmallVec in SwitchTargetsJonas Schievink-3/+1
This allows building common SwitchTargets (eg. for `if`s) without allocation.
2020-10-10Refactor how SwitchInt stores jump targetsJonas Schievink-6/+8
2020-10-06Rollup merge of #77559 - camelid:fix-rustdoc-warnings-invalid-rust-syntax, ↵Yuki Okushi-1/+2
r=lcnr Fix rustdoc warnings about invalid Rust syntax
2020-10-05Renamed tests to avoid exceeding Windows max path limitRich Kadel-7/+1
2020-10-05Updates to experimental coverage counter injectionRich Kadel-48/+92
This is a combination of 18 commits. Commit #2: Additional examples and some small improvements. Commit #3: fixed mir-opt non-mir extensions and spanview title elements Corrected a fairly recent assumption in runtest.rs that all MIR dump files end in .mir. (It was appending .mir to the graphviz .dot and spanview .html file names when generating blessed output files. That also left outdated files in the baseline alongside the files with the incorrect names, which I've now removed.) Updated spanview HTML title elements to match their content, replacing a hardcoded and incorrect name that was left in accidentally when originally submitted. Commit #4: added more test examples also improved Makefiles with support for non-zero exit status and to force validation of tests unless a specific test overrides it with a specific comment. Commit #5: Fixed rare issues after testing on real-world crate Commit #6: Addressed PR feedback, and removed temporary -Zexperimental-coverage -Zinstrument-coverage once again supports the latest capabilities of LLVM instrprof coverage instrumentation. Also fixed a bug in spanview. Commit #7: Fix closure handling, add tests for closures and inner items And cleaned up other tests for consistency, and to make it more clear where spans start/end by breaking up lines. Commit #8: renamed "typical" test results "expected" Now that the `llvm-cov show` tests are improved to normally expect matching actuals, and to allow individual tests to override that expectation. Commit #9: test coverage of inline generic struct function Commit #10: Addressed review feedback * Removed unnecessary Unreachable filter. * Replaced a match wildcard with remining variants. * Added more comments to help clarify the role of successors() in the CFG traversal Commit #11: refactoring based on feedback * refactored `fn coverage_spans()`. * changed the way I expand an empty coverage span to improve performance * fixed a typo that I had accidently left in, in visit.rs Commit #12: Optimized use of SourceMap and SourceFile Commit #13: Fixed a regression, and synched with upstream Some generated test file names changed due to some new change upstream. Commit #14: Stripping out crate disambiguators from demangled names These can vary depending on the test platform. Commit #15: Ignore llvm-cov show diff on test with generics, expand IO error message Tests with generics produce llvm-cov show results with demangled names that can include an unstable "crate disambiguator" (hex value). The value changes when run in the Rust CI Windows environment. I added a sed filter to strip them out (in a prior commit), but sed also appears to fail in the same environment. Until I can figure out a workaround, I'm just going to ignore this specific test result. I added a FIXME to follow up later, but it's not that critical. I also saw an error with Windows GNU, but the IO error did not specify a path for the directory or file that triggered the error. I updated the error messages to provide more info for next, time but also noticed some other tests with similar steps did not fail. Looks spurious. Commit #16: Modify rust-demangler to strip disambiguators by default Commit #17: Remove std::process::exit from coverage tests Due to Issue #77553, programs that call std::process::exit() do not generate coverage results on Windows MSVC. Commit #18: fix: test file paths exceeding Windows max path len
2020-10-05Auto merge of #77552 - ecstatic-morse:body-def-id, r=lcnrbors-13/+10
Replace `(Body, DefId)` with `Body` where possible Follow-up to #77430. I `grep`-ed for parameter lists in which a `Body` appeared within a few lines of a `DefId`, so it's possible that I missed some cases, but this should be pretty complete. Most of these changes were mechanical, but there's a few places where I started calling things "caller" and "callee" when multiple `DefId`s were in-scope at once. Also, we should probably have a helper function on `Body` that returns a `LocalDefId`. I can do that in this PR or in a follow-up.
2020-10-04Fix rustdoc warnings about invalid Rust syntaxCamelid-1/+2
2020-10-05Auto merge of #77466 - Aaron1011:reland-drop-tree, r=matthewjasperbors-37/+19
Re-land PR #71840 (Rework MIR drop tree lowering) PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526), so let's try re-landing this PR. I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output), making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those. r? `@matthewjasper`
2020-10-04Replace `(Body, DefId)` with `Body` where possibleDylan MacKenzie-13/+10
A `Body` now contains its `MirSource`, which in turn contains the `DefId` of the item associated with the `Body`.
2020-10-04Remember the `MirSource` for each `Body`Dylan MacKenzie-39/+28
2020-10-04Fix rebase falloutAaron Hill-8/+3
2020-10-04Reduce the number of drop-flag assignments in unwind pathsMatthew Jasper-35/+11
2020-10-04Defer creating drop trees in MIR lowering until leaving that scopeMatthew Jasper-1/+12
2020-09-19Stop using the `const_eval` query for initializers of staticsOliver Scherer-5/+2
As a side effect, we now represent most promoteds as `ConstValue::Scalar` again. This is useful because all implict promoteds are just references anyway and most explicit promoteds are numeric arguments to `asm!` or SIMD instructions.
2020-09-16Rollup merge of #76794 - richkadel:graphviz-font, r=ecstatic-morseTyler Mandry-3/+3
Make graphviz font configurable Alternative to PR #76776. To change the graphviz output to use an alternative `fontname` value, add a command line option like: `rustc --graphviz-font=monospace`. r? @ecstatic-morse
2020-09-16Make graphviz font configurableRich Kadel-3/+3
Alternative to PR ##76776. To change the graphviz output to use an alternative `fontname` value, add a command line option like: `rustc --graphviz-font=monospace`.
2020-09-10Note when a a move/borrow error is caused by a deref coercionAaron Hill-6/+7
Fixes #73268 When a deref coercion occurs, we may end up with a move error if the base value has been partially moved out of. However, we do not indicate anywhere that a deref coercion is occuring, resulting in an error message with a confusing span. This PR adds an explicit note to move errors when a deref coercion is involved. We mention the name of the type that the deref-coercion resolved to, as well as the `Deref::Target` associated type being used.
2020-09-10use push(char) instead of push_str(&str) to add single chars to stringsMatthias Krüger-1/+1
clippy::single-char-push-str
2020-09-10Auto merge of #75573 - Aaron1011:feature/const-mutation-lint, r=oli-obkbors-0/+37
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 #76500 - richkadel:mir-graphviz-dark, r=tmandryTyler Mandry-7/+22
Add -Zgraphviz_dark_mode and monospace font fix Many developers use a dark theme with editors and IDEs, but this typically doesn't extend to graphviz output. When I bring up a MIR graphviz document, the white background is strikingly bright. This new option changes the colors used for graphviz output to work better in dark-themed UIs. <img width="1305" alt="Screen Shot 2020-09-09 at 3 00 31 PM" src="https://user-images.githubusercontent.com/3827298/92659478-4b9bff00-f2ad-11ea-8894-b40d3a873cb9.png"> Also fixed the monospace font for common graphviz renders (e.g., VS Code extensions), as described in https://github.com/rust-lang/rust/pull/76500#issuecomment-689837948 **Before:** <img width="943" alt="Screen Shot 2020-09-09 at 2 48 44 PM" src="https://user-images.githubusercontent.com/3827298/92658939-47231680-f2ac-11ea-97ac-96727e4dd622.png"> **Now with fix:** <img width="943" alt="Screen Shot 2020-09-09 at 2 49 02 PM" src="https://user-images.githubusercontent.com/3827298/92658959-51451500-f2ac-11ea-9aae-de982d466d6a.png">
2020-09-09Also fixed monospace font for d3-graphviz engineRich Kadel-1/+1
VS code graphviz extensions use d3-graphviz, which supports `Courier` fontname but does not support `monospace`. This caused graphs to render poorly because the text sizes were wrong.
2020-09-08Add -Zgraphviz_dark_modeRich Kadel-7/+22
Many developers use a dark theme with editors and IDEs, but this typically doesn't extend to graphviz output. When I bring up a MIR graphviz document, the white background is strikingly bright. This new option changes the colors used for graphviz output to work better in dark-themed UIs.
2020-09-07Add CONST_ITEM_MUTATION lintAaron Hill-0/+37
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-06Improved the MIR spanview outputRich Kadel-84/+295
* Adds missing "tail" spans (spans that continue beyond the end of overlapping spans) * Adds a caret to highlight empty spans associated with MIR elements that have a position, but otherwise would not be visible. * Adds visual pointing brackets at the beginning and end of each span
2020-09-04Change ty.kind to a methodLeSeulArtichaut-5/+5
2020-08-31Add new `-Z dump-mir-spanview` optionRich Kadel-0/+473
Similar to `-Z dump-mir-graphviz`, this adds the option to write HTML+CSS files that allow users to analyze the spans associated with MIR elements (by individual statement, just terminator, or overall basic block). This PR was split out from PR #76004, and exposes an API for spanview HTML+CSS files that is also used to analyze code regions chosen for coverage instrumentation (in a follow-on PR). Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-08-30mv compiler to compiler/mark-0/+3270
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 00:19:32 +0000