- 02 9月, 2021 4 次提交
- 22 8月, 2021 2 次提交
-
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
- 04 8月, 2021 1 次提交
-
-
由 Amanieu d'Antras 提交于
This was removed by #85284 in favor of -Zprofiler-runtime=<name>. However the suggested -Zprofiler-runtime=None doesn't work because "None" is treated as a crate name.
-
- 18 7月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 15 7月, 2021 1 次提交
-
-
由 Joshua Nelson 提交于
Proc-macros are always compiled for the host, so this should be the same in every way as recompiling the crate. I am not sure why the previous code special-cased the target, since the compiler properly gives an error when trying to load a crate for a different host: ``` error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu --> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2 | LL | dependency::is_64(); | ^^^^^^^^^^ | = note: the following crate versions were found: crate `dependency`, target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so ``` I think another possible fix is to remove the check altogether. But I'm not sure, and this fix works, so I'm not making the larger change here.
-
- 14 7月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 07 7月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 06 7月, 2021 1 次提交
-
- 17 6月, 2021 1 次提交
-
-
由 Alan Egerton 提交于
-
- 09 6月, 2021 1 次提交
-
-
由 bjorn3 提交于
-
- 07 6月, 2021 1 次提交
-
- 01 6月, 2021 1 次提交
-
-
由 Camille Gillot 提交于
-
- 31 5月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 30 5月, 2021 1 次提交
-
-
由 bjorn3 提交于
-
- 17 5月, 2021 1 次提交
-
-
由 Alan Egerton 提交于
Currently, if `-Zinstrument-coverage` is enabled, the target is linked against the `library/profiler_builtins` crate (which pulls in LLVM's compiler-rt runtime). This option enables backends to specify an alternative runtime crate for handling injected instrumentation calls.
-
- 26 4月, 2021 1 次提交
-
-
由 Joshua Nelson 提交于
- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help. - Add a note about `#![no_std]` if `std` is missing but not core - On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note that std may be unsupported if `std` is missing but not core - Don't suggest `#![no_std]` when the load isn't injected by the compiler
-
- 26 3月, 2021 1 次提交
-
-
由 Michael Woerister 提交于
-
- 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.
-
- 08 3月, 2021 4 次提交
- 08 2月, 2021 1 次提交
-
-
由 Jeremy Fitzhardinge 提交于
This allows a build system to indicate a location in its own dependency specification files (eg Cargo's `Cargo.toml`) which can be reported along side any unused crate dependency. This supports several types of location: - 'json' - provide some json-structured data, which is included in the json diagnostics in a `tool_metadata` field - 'raw' - emit the provided string into the output. This also appears as a json string in `tool_metadata`. If no `--extern-location` is explicitly provided then a default json entry of the form `"tool_metadata":{"name":<cratename>,"path":<cratepath>}` is emitted.
-
- 03 2月, 2021 1 次提交
-
-
由 Michael Woerister 提交于
This allows to directly map from a DefPathHash to the crate it originates from, without constructing side tables to do that mapping. It also allows to reliably and cheaply check for DefPathHash collisions.
-
- 29 1月, 2021 1 次提交
-
-
由 Ryan Levick 提交于
-
- 27 1月, 2021 1 次提交
-
-
由 Ryan Levick 提交于
-
- 15 1月, 2021 1 次提交
-
-
由 LingMan 提交于
-
- 15 12月, 2020 1 次提交
-
-
由 Rich Kadel 提交于
Adds checks for: * `no_core` attribute * explicitly-enabled `legacy` symbol mangling * mir_opt_level > 1 (which enables inlining) I removed code from the `Inline` MIR pass that forcibly disabled inlining if `-Zinstrument-coverage` was set. The default `mir_opt_level` does not enable inlining anyway. But if the level is explicitly set and is greater than 1, I issue a warning. The new warnings show up in tests, which is much better for diagnosing potential option conflicts in these cases.
-
- 30 10月, 2020 1 次提交
-
-
由 Joshua Nelson 提交于
-
- 30 8月, 2020 2 次提交
-
-
由 mark 提交于
-
由 Joshua Nelson 提交于
-
- 18 8月, 2020 1 次提交
-
-
由 Ujjwal Sharma 提交于
-
- 16 8月, 2020 1 次提交
-
-
由 Gurpreet Singh 提交于
-
- 08 8月, 2020 2 次提交
-
-
由 Nicholas Nethercote 提交于
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This means they are accessed via the `Session`, rather than via TLS. A few `Attr` methods and `librustc_ast` functions are now methods of `Session`. All of this required passing a `Session` to lots of functions that didn't already have one. Some of these functions also had arguments removed, because those arguments could be accessed directly via the `Session` argument. `contains_feature_attr()` was dead, and is removed. Some functions were moved from `librustc_ast` elsewhere because they now need to access `Session`, which isn't available in that crate. - `entry_point_type()` --> `librustc_builtin_macros` - `global_allocator_spans()` --> `librustc_metadata` - `is_proc_macro_attr()` --> `Session`
-
由 Nicholas Nethercote 提交于
These arguments are never `None`.
-
- 02 8月, 2020 1 次提交
-
-
由 Camille GILLOT 提交于
-