- 11 5月, 2021 1 次提交
-
-
由 b-naber 提交于
-
- 30 4月, 2021 2 次提交
-
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
- 29 4月, 2021 1 次提交
-
-
由 crlf0710 提交于
-
- 19 4月, 2021 1 次提交
-
-
由 klensy 提交于
-
- 17 4月, 2021 1 次提交
-
-
由 Aaron Hill 提交于
Fixes #84252 This query reads from untracked global state in `CStore`.
-
- 05 4月, 2021 1 次提交
-
-
由 hi-rustin 提交于
resolve conflicts
-
- 04 4月, 2021 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 31 3月, 2021 2 次提交
-
-
由 Jack Huey 提交于
-
由 Oli Scherer 提交于
-
- 25 3月, 2021 2 次提交
- 24 3月, 2021 2 次提交
- 22 3月, 2021 1 次提交
-
-
由 Nikita Popov 提交于
Such structures may contain self-references, in which case the same location may be accessible through a pointer that is not based-on the noalias pointer. This is still grey area as far as language semantics are concerned, but checking for !Unpin as an indicator for self-referential sturctures seems like a good approach for the meantime.
-
- 20 3月, 2021 1 次提交
-
-
由 Rich Kadel 提交于
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.
-
- 16 3月, 2021 2 次提交
-
-
由 Tomasz Miąsko 提交于
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.
-
由 Aaron Hill 提交于
This query reads from global untracked state, so it always needs to be evaluated.
-
- 12 3月, 2021 2 次提交
-
-
由 Oli Scherer 提交于
-
由 Oli Scherer 提交于
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.
-
- 10 3月, 2021 2 次提交
-
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
- 25 2月, 2021 1 次提交
-
-
由 Joshua Nelson 提交于
This made the generated docs look strange: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.param_env_reveal_all_normalized
-
- 24 2月, 2021 1 次提交
-
-
由 Ellen 提交于
-
- 20 2月, 2021 4 次提交
-
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
- 16 2月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 09 2月, 2021 1 次提交
-
-
由 Mark Rousskov 提交于
In practice we never used the borrowed variant anyway.
-
- 06 2月, 2021 1 次提交
-
-
由 Santiago Pastorino 提交于
This reverts commit b4def89d, reversing changes made to 7dc1e852.
-
- 01 2月, 2021 2 次提交
-
-
由 Julian Wollersberger 提交于
-
由 Julian Wollersberger 提交于
-
- 24 1月, 2021 1 次提交
-
-
由 oli 提交于
-
- 23 1月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 17 1月, 2021 1 次提交
-
-
由 Bastian Kauschke 提交于
-
- 14 1月, 2021 1 次提交
-
-
由 bjorn3 提交于
It overwrites the definition from rustc_metadata
-
- 13 1月, 2021 3 次提交
-
-
由 Nadrieril 提交于
Since `DefIdForest` contains 0 or 1 elements the large majority of the time, by allocating only in the >1 case we avoid almost all allocations, compared to `Arc<SmallVec<[DefId;1]>>`. This shaves off 0.2% on the benchmark that stresses uninhabitedness checking.
-
由 Nadrieril 提交于
-
由 Tyson Nottingham 提交于
-