about summary refs log tree commit diff
path: root/src/test/incremental
AgeCommit message (Collapse)AuthorLines
2020-10-26simplify-locals: Remove unused assignments regardless of rvalue kindTomasz Miąsko-2/+2
2020-10-26simplify-locals: Remove unused set-discriminant statementsTomasz Miąsko-1/+1
Update affected ui & incremental tests to use a user declared variable bindings instead of temporaries. The former are preserved because of debuginfo, the latter are not.
2020-10-11Auto merge of #76859 - Aaron1011:fix/llvm-cgu-reuse, r=davidtwco,nikicbors-2/+53
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse During incremental ThinLTO compilation, we attempt to re-use the optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do so. Up until now, 'safe' has meant that the set of modules that our current modules imports from/exports to is unchanged from the previous compilation session. See PR #67020 and PR #71131 for more details. However, this turns out be insufficient to guarantee that it's safe to reuse the post-LTO module (i.e. that optimizing the pre-LTO module would produce the same result). When LLVM optimizes a module during ThinLTO, it may look at other information from the 'module index', such as whether a (non-imported!) global variable is used. If this information changes between compilation runs, we may end up re-using an optimized module that (for example) had dead-code elimination run on a function that is now used by another module. Fortunately, LLVM implements its own ThinLTO module cache, which is used when ThinLTO is performed by a linker plugin (e.g. when clang is used to compile a C proect). Using this cache directly would require extensive refactoring of our code - but fortunately for us, LLVM provides a function that does exactly what we need. The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash from all data that might influence the result of ThinLTO on a module. In addition to the module imports/exports that we manually track, it also hashes information about global variables (e.g. their liveness) which might be used during optimization. By using this function, we shouldn't have to worry about new LLVM passes breaking our module re-use behavior. In LLVM, the output of this function forms part of the filename used to store the post-ThinLTO module. To keep our current filename structure intact, this PR just writes out the mapping 'CGU name -> Hash' to a file. To determine if a post-LTO module should be reused, we compare hashes from the previous session. This should unblock PR #75199 - by sheer chance, it seems to have hit this issue due to the particular CGU partitioning and optimization decisions that end up getting made.
2020-10-06Remove predicates on associated types from traitsMatthew Jasper-1/+4
These need to only be bounds to avoid cycle errors in trait checking.
2020-10-06Fix tests and bootstrapMatthew Jasper-1/+1
2020-09-19Update incremental testsOliver Scherer-1/+1
2020-09-17Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuseAaron Hill-2/+53
During incremental ThinLTO compilation, we attempt to re-use the optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do so. Up until now, 'safe' has meant that the set of modules that our current modules imports from/exports to is unchanged from the previous compilation session. See PR #67020 and PR #71131 for more details. However, this turns out be insufficient to guarantee that it's safe to reuse the post-LTO module (i.e. that optimizing the pre-LTO module would produce the same result). When LLVM optimizes a module during ThinLTO, it may look at other information from the 'module index', such as whether a (non-imported!) global variable is used. If this information changes between compilation runs, we may end up re-using an optimized module that (for example) had dead-code elimination run on a function that is now used by another module. Fortunately, LLVM implements its own ThinLTO module cache, which is used when ThinLTO is performed by a linker plugin (e.g. when clang is used to compile a C proect). Using this cache directly would require extensive refactoring of our code - but fortunately for us, LLVM provides a function that does exactly what we need. The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash from all data that might influence the result of ThinLTO on a module. In addition to the module imports/exports that we manually track, it also hashes information about global variables (e.g. their liveness) which might be used during optimization. By using this function, we shouldn't have to worry about new LLVM passes breaking our module re-use behavior. In LLVM, the output of this function forms part of the filename used to store the post-ThinLTO module. To keep our current filename structure intact, this PR just writes out the mapping 'CGU name -> Hash' to a file. To determine if a post-LTO module should be reused, we compare hashes from the previous session. This should unblock PR #75199 - by sheer chance, it seems to have hit this issue due to the particular CGU partitioning and optimization decisions that end up getting made.
2020-09-02pretty: trim paths of unique symbolsDan Aloni-2/+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-07-26Share serialization optimization between incr and metadataAaron Hill-1/+0
2020-07-26Add test for hygiene caching issueAaron Hill-0/+85
2020-07-17Rename TypeckTables to TypeckResults.Valentin Lazureanu-171/+171
2020-07-15mir_built is a lieBastian Kauschke-152/+152
2020-05-25Auto merge of #72520 - jonas-schievink:cleanup-userty, r=matthewjasperbors-1/+1
Clear MIR local type annotations after borrowck
2020-05-24Clear MIR local type annotations after borrowckJonas Schievink-1/+1
2020-05-23Add missing ASM arena declaration to librustc_middleAaron Hill-0/+22
Fixes #72386 This type also needs to get allocated on the `librustc_middle` arena when we deserialize MIR.
2020-05-16Rollup merge of #72045 - RalfJung:incomplete-unsound, r=petrochenkovRalf Jung-2/+2
Incomplete features can also be unsound Some incomplete features do not just ICE, they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029, and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that. While at it I also added a link to the tracking issue, which hopefully should explain what is incomplete/unsound about the feature.
2020-05-09Fix disagreeement about CGU reuse and LTOAlex Crichton-0/+17
This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006
2020-05-09adjust testsRalf Jung-2/+2
2020-04-23Moving more build-pass tests to check-passVal Markovic-1/+1
One or two tests became build-pass without the FIXME because they really needed build-pass (were failing without it). Helps with #62277
2020-04-20const prop: don't special case return placeJonas Schievink-4/+4
2020-04-14Tests.Felix S. Klock II-0/+52
Namely, a regression test for issue #69798 (export added), and the inverse of that test (export removd).
2020-03-31update testsBastian Kauschke-1/+1
2020-03-26Update tests to use llvm_asm!Amanieu d'Antras-73/+73
2020-03-19hir: replace "items" terminology with "nodes" where appropriate.Eduard-Mihai Burtescu-352/+352
2020-03-18Rollup merge of #69838 - Centril:expand-module, r=petrochenkovMazdak Farrokhzad-4/+2
Expansion-driven outline module parsing After this PR, the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead, the parser only leaves `mod foo;` in place in the AST, with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist, but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov
2020-03-18fix pre-expansion linting infraMazdak Farrokhzad-4/+2
2020-03-17Update tests for erasing regions in typeckMatthew Jasper-4/+4
2020-03-14Add test for #69596John Kåre Alsaker-0/+21
2020-03-14Update ich_nested_items.rsJohn Kåre Alsaker-8/+11
2020-03-14Format function_interfaces.rsJohn Kåre Alsaker-46/+40
2020-03-14Replace `Hir` with `hir_owner` in testsJohn Kåre Alsaker-472/+472
2020-03-14Replace `HirBody` with `hir_owner_items` in testsJohn Kåre Alsaker-352/+352
2020-03-06fix various typosMatthias Krüger-3/+3
2020-02-28Auto merge of #68505 - skinny121:canonicalize-const-eval-inputs, r=nikomatsakisbors-0/+23
Canonicalize inputs to const eval where needed Canonicalize inputs to const eval, so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection. This is a reattempt of #67717, in a far less invasive way. Fixes #68477 r? @nikomatsakis cc @eddyb
2020-02-20Revert "Rollup merge of #69280 - ↵Dylan MacKenzie-2/+1
ecstatic-morse:promote-shuffle-no-special-case, r=petrochenkov" This reverts commit 61d3b6dedb1ec1f3e3cbd3d66b1a3453225bc37c, reversing changes made to c6ad1e2c2a0c7e48537617d36085f866fa6a65a3.
2020-02-20Rollup merge of #69185 - RalfJung:const-prop-lints, r=oli-obkMazdak Farrokhzad-2/+2
Unify and improve const-prop lints Add a single helper method for all lints emitted by const-prop, and make that lint different from the CTFE `const_err` lint. Also consistently check overflow on *arithmetic*, not on the assertion, to make behavior the same for debug and release builds. See [this summary comment](https://github.com/rust-lang/rust/pull/69185#issuecomment-587924754) for details and the latest status. In terms of lint formatting, I went for what seems to be the better style: have a general message above the code, and then a specific message at the span: ``` error: this arithmetic operation will overflow --> $DIR/const-err2.rs:21:18 | LL | let a_i128 = -std::i128::MIN; | ^^^^^^^^^^^^^^^ attempt to negate with overflow ``` We could also just have the specific message above and no text at the span if that is preferred. I also converted some of the existing tests to use compiletest revisions, so that the same test can check a bunch of different compile flags. Fixes https://github.com/rust-lang/rust/issues/69020. Helps with https://github.com/rust-lang/rust/issues/69021: debug/release are now consistent, but the assoc-const test in that issue still fails (there is a FIXME in the PR for this). The reason seems to be that const-prop notices the assoc const in `T::N << 42` and does not even bother calling `const_prop` on that operation. Has no effect on https://github.com/rust-lang/rust/issues/61821; the duplication there has entirely different reasons.
2020-02-20Add regression test for issue 68477.Ben Lewis-0/+23
2020-02-18Add `#[rustc_args_required_const]` to `simd_shuffle` testsDylan MacKenzie-1/+2
2020-02-18better lint namesRalf Jung-1/+1
2020-02-15fix incremental testsRalf Jung-2/+2
2020-02-06Move the `krate` method to Hir and remove the Krate dep nodeJohn Kåre Alsaker-19/+13
2020-01-27Collisions in the dep-graph due to path-reuse are rare but can occur.Felix S. Klock II-0/+13
So, instead of ICE'ing, just fail to mark green in such cases (for `DepKind::{Hir, HirBody, CrateMetadata}`). Fix #62649.
2020-01-01Add a test for #37333Michal Terepeta-0/+51
The test checks that we reuse the CGU of a crate when the implementation details of an `extern crate` have changed. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
2019-12-20General purpose teest cases contributed by mw.Felix S. Klock II-0/+136
2019-12-06Make try_mark_previous_green aware of cycles.Alex Aktsipetrov-0/+15
2019-11-27rustc: move debug info from LocalDecl and UpvarDecl into a dedicated ↵Eduard-Mihai Burtescu-8/+8
VarDebugInfo.
2019-11-21Fix broken incremental testDylan MacKenzie-2/+1
This test does not actually emit any warnings, since `#![allow(warnings)]` was specified. `compiletest` was erroneously ignoring `//~` tests and looking only for `//[X]~` ones. As a result of the changes in the previous commit, we now look for `//~` comments in incremental tests and expect them to appear in *all* revisions.
2019-11-20Rollup merge of #66060 - traxys:test_65401, r=michaelwoeristerMazdak Farrokhzad-0/+8
Making ICEs and test them in incremental This adds: - A way to make the compiler ICE - A way to check for ICE in `cfail` tests with `should-ice` - A regression test for issue #65401 I am not sure the attribute added `should-ice` is the best for this job
2019-11-11[mir-opt] Turn on the `ConstProp` pass by defaultWesley Wiser-7/+7
perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result, we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.
2019-11-10Rollup merge of #66216 - wesleywiser:const_prop_codegen_improvements, r=oli-obkYuki Okushi-2/+2
[mir-opt] Handle return place in ConstProp and improve SimplifyLocals pass Temporarily rebased on top of #66074. The top 2 commits are new. r? @oli-obk
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 03:50:28 +0000