about summary refs log tree commit diff
path: root/src/test/incremental
AgeCommit message (Collapse)AuthorLines
2021-04-29Add integration test for `--remap-pathh-prefix`Joshua Nelson-2/+5
2021-04-16Mark `has_global_allocator` query as `eval_always`Aaron Hill-0/+12
Fixes #84252 This query reads from untracked global state in `CStore`.
2021-04-03Remove attribute `#[link_args]`Vadim Petrochenkov-16/+0
2021-03-31Add var to BoundRegion. Add query to get bound vars for applicable items.Jack Huey-6/+6
2021-03-24Use `EvaluatedToOkModuloRegions` whenever we erase regionsAaron Hill-0/+184
Fixes #80691 When we evaluate a trait predicate, we convert an `EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any regions. We cache the result under a region-erased 'freshened' predicate, so `EvaluatedToOk` may not be correct for other predicates that have the same cache key.
2021-03-22Err if the debugging options are not passed.Camille GILLOT-1/+3
2021-03-13Avoid sorting predicates by `DefId`Aaron Hill-0/+31
Fixes issue #82920 Even if an item does not change between compilation sessions, it may end up with a different `DefId`, since inserting/deleting an item affects the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash` in the incremental compilation system, which is stable in the face of changes to unrelated items. In particular, the query system will consider the inputs to a query to be unchanged if any `DefId`s in the inputs have their `DefPathHash`es unchanged. Queries are pure functions, so the query result should be unchanged if the query inputs are unchanged. Unfortunately, it's possible to inadvertantly make a query result incorrectly change across compilations, by relying on the specific value of a `DefId`. Specifically, if the query result is a slice that gets sorted by `DefId`, the precise order will depend on how the `DefId`s got assigned in a particular compilation session. If some definitions end up with different `DefId`s (but the same `DefPathHash`es) in a subsequent compilation session, we will end up re-computing a *different* value for the query, even though the query system expects the result to unchanged due to the unchanged inputs. It turns out that we have been sorting the predicates computed during `astconv` by their `DefId`. These predicates make their way into the `super_predicates_that_define_assoc_type`, which ends up getting used to compute the vtables of trait objects. This, re-ordering these predicates between compilation sessions can lead to undefined behavior at runtime - the query system will re-use code built with a *differently ordered* vtable, resulting in the wrong method being invoked at runtime. This PR avoids sorting by `DefId` in `astconv`, fixing the miscompilation. However, it's possible that other instances of this issue exist - they could also be easily introduced in the future. To fully fix this issue, we should 1. Turn on `-Z incremental-verify-ich` by default. This will cause the compiler to ICE whenver an 'unchanged' query result changes between compilation sessions, instead of causing a miscompilation. 2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it difficult to introduce ICEs in the first place.
2021-03-09Bless tests.Camille GILLOT-19/+19
2021-02-05Revert "Auto merge of #79637 - spastorino:revert-trait-inheritance-self, ↵Santiago Pastorino-5/+5
r=Mark-Simulacrum" This reverts commit b4def89d76896eec73b4af33642ba7e5eb53c567, reversing changes made to 7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb.
2021-01-14Auto merge of #79328 - c410-f3r:hir-if, r=matthewjasperbors-1/+1
Reintroduce hir::ExprKind::If Basically copied and paste #59288/https://github.com/rust-lang/rust-clippy/pull/4080 with some modifications. The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces, any help with the following list is welcome. - [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051) - [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d) - [x] **New note regarding `assert!`**: [Modified but not "wrong". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5) - [x] **Inverted report location**: [Modified but not "wrong". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691) - [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95) - [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)
2021-01-13Properly handle `SyntaxContext` of dummy spans in incr compAaron Hill-0/+10
Fixes #80336 Due to macro expansion, we may end up with spans with an invalid location and non-root `SyntaxContext`. This commits preserves the `SyntaxContext` of such spans in the incremental cache, and ensures that we always hash the `SyntaxContext` when computing the `Fingerprint` of a `Span` Previously, we would discard the `SyntaxContext` during serialization to the incremental cache, causing the span's `Fingerprint` to change across compilation sessions.
2021-01-13Update code to account for extern ABI requirementMark Rousskov-2/+2
2021-01-13Update tests for extern block lintingMark Rousskov-3/+5
2021-01-11Revert "Auto merge of #76896 - spastorino:codegen-inline-fns2, ↵Santiago Pastorino-15/+3
r=davidtwco,wesleywiser" This reverts commit ddf2cc7f8eb34f1a63b491d6a52e3e8208393c09, reversing changes made to 937f629535f38c655267f1ed21ce6830f592f5df.
2021-01-08Auto merge of #76896 - spastorino:codegen-inline-fns2, r=davidtwco,wesleywiserbors-3/+15
Do not make local copies of inline fns in debug mode r? `@wesleywiser` cc `@rust-lang/wg-incr-comp` If this is correct it supersedes https://github.com/rust-lang/rust/pull/76889 Related to #54089
2021-01-07Reintroduce hir::ExprKind::IfCaio-1/+1
2020-12-10Use `def_path_hash_to_def_id` when re-using a `RawDefId`Aaron Hill-0/+8
Fixes #79890 Previously, we just copied a `RawDefId` from the 'old' map to the 'new' map. However, the `RawDefId` for a given `DefPathHash` may be different in the current compilation session. Using `def_path_hash_to_def_id` ensures that the `RawDefId` we use is valid in the current session.
2020-12-09Update two failing incremental tests for the new behaviorWesley Wiser-3/+15
On the nopt builders, we disable optimization by default for all tests which causes the new behavior to take effect and causes the tests to fail when they should not. By passing the `-O` flag explicitly, we will always run these tests with optimizations enabled.
2020-12-04Properly re-use def path hash in incremental modeAaron Hill-0/+20
Fixes #79661 In incremental compilation mode, we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache, and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache, we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However, PR #74967 didn't do this in all cases, leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.
2020-12-02Revert "Auto merge of #79209 - spastorino:trait-inheritance-self, ↵Santiago Pastorino-5/+5
r=nikomatsakis" This reverts commit 349b3b324dade7ca638091db93ba08bbc443c63d, reversing changes made to b776d1c3e3db8befabb123ebb1e46c3531eaed46.
2020-11-29Auto merge of #79209 - spastorino:trait-inheritance-self, r=nikomatsakisbors-5/+5
Allow Trait inheritance with cycles on associated types Fixes #35237 r? `@nikomatsakis` cc `@estebank`
2020-11-27Bless testsSantiago Pastorino-5/+5
2020-11-26Update test.Camille GILLOT-78/+53
2020-11-20Remove FIXME comment from incrementalDaiki Ihara-6/+6
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 23:44:05 +0000