| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
first stage of implementing LLVM code coverage
This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST).
This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation.
This initial version only injects counters at the top of each function, and does not yet implement the required coverage map.
Upcoming PRs will add the coverage map, and add more counters and/or counter expressions for each conditional code branch.
Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
***[I put together some development notes here, under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
|
|
Disallow loading crates with non-ascii identifier name.
This turns off external crate loading with non-ascii identifier names.
cc #55467.
|
|
If config.toml `profiler = false`, the test/mir-opt/instrument_coverage
test is ignored. Otherwise, this patch ensures the profiler_runtime is
loaded when -Zinstrument-coverage is enabled. Confirmed that this works
for MacOS.
|
|
|
|
|
|
`--extern proc_macro` is used to add the proc_macro crate to the extern
prelude for all procmacros. In general pathless `--extern` only references
sysroot/standard libraries and so should be exempt from
unused-crate-dependencies warnings.
|
|
This will print a diagnostic for crates which are mentioned as `--extern`
arguments on the command line, but are never referenced from the source.
This diagnostic is controlled by `-Wunused-crate-dependencies` or
`#![warn(unused_crate_dependencies)]` and is "allow" by default.
There are cases where certain crates need to be linked in but are not
directly referenced - for example if they are providing symbols for C
linkage. In this case the warning can be suppressed with
`use needed_crate as _;`.
Thanks to @petrochenkov for simplified core.
Resolves issue #57274
|
|
|
|
|
|
Remove support for self-opening
This was only used for linkage test cases, which is already covered by
the [run-make-fulldeps/symbol-visibility test](https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/symbol-visibility/Makefile) -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
This fixes #10379 and resolves #10356 by removing the test case (and underlying support in the compiler). AFAICT, the better way to test visibility is via nm, like the symbol visibility test. It seems like that's sufficient; I suspect that given that we don't use this we should just drop it (android is tier 2 anyway). But happy to hear otherwise.
|
|
This was only used for linkage test cases, which is already covered by
the run-make-fulldeps/symbol-visibility test -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
|
|
These are changes that would be needed if we add `#[must_use]` to
`Option::map`, per #71484.
|
|
|
|
|
|
|
|
|
|
Refactorings to get rid of rustc_codegen_utils
r? @eddyb
cc #45276
After this, the only modules left in `rustc_codegen_utils` are
- `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc?
- ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate)
I don't mind doing either of the above as part of this PR or a followup if you want.
|
|
|
|
|
|
|
|
|
|
|
|
rustc_metadata: Load metadata for indirect macro-only dependencies
Imagine this dependency chain between crates
```
Executable crate -> Library crate -> Macro crate
```
where "Library crate" uses the macros from "Macro crate" for some code generation, but doesn't reexport them any further.
Currently, when compiling "Executable crate" we don't even load metadata for it, because why would we want to load any metadata from "Macro crate" if it already did all its code generation job when compiling "Library crate".
Right?
Wrong!
Hygiene data and spans (https://github.com/rust-lang/rust/issues/68686, https://github.com/rust-lang/rust/pull/68941) from "Macro crate" still may need to be decoded from "Executable crate".
So we'll have to load them properly.
Questions:
- How this will affect compile times for larger crate trees in practice? How to measure it?
Hygiene/span encoding/decoding will necessarily slow down compilation because right now we just don't do some work that we should do, but this introduces a whole new way to slow down things. E.g. loading metadata for `syn` (and its dependencies) when compiling your executable if one of its library dependencies uses it.
- We are currently detecting whether a crate reexports macros from "Macro crate" or not, could we similarly detect whether a crate "reexports spans" and keep it unloaded if it doesn't?
Or at least "reexports important spans" affecting hygiene, we can probably lose spans that only affect diagnostics.
|
|
|
|
|
|
|
|
|
|
|
|
build-std compatible sanitizer support
### Motivation
When using `-Z sanitizer=*` feature it is essential that both user code and
standard library is instrumented. Otherwise the utility of sanitizer will be
limited, or its use will be impractical like in the case of memory sanitizer.
The recently introduced cargo feature build-std makes it possible to rebuild
standard library with arbitrary rustc flags. Unfortunately, those changes alone
do not make it easy to rebuild standard library with sanitizers, since runtimes
are dependencies of std that have to be build in specific environment,
generally not available outside rustbuild process. Additionally rebuilding them
requires presence of llvm-config and compiler-rt sources.
The goal of changes proposed here is to make it possible to avoid rebuilding
sanitizer runtimes when rebuilding the std, thus making it possible to
instrument standard library for use with sanitizer with simple, although
verbose command:
```
env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu
```
### Implementation
* Sanitizer runtimes are no long packed into crates. Instead, libraries build
from compiler-rt are used as is, after renaming them into `librusc_rt.*`.
* rustc obtains runtimes from target libdir for default sysroot, so that
they are not required in custom build sysroots created with build-std.
* The runtimes are only linked-in into executables to address issue #64629.
(in previous design it was hard to avoid linking runtimes into static
libraries produced by rustc as demonstrated by sanitizer-staticlib-link
test, which still passes despite changes made in #64780).
cc @kennytm, @japaric, @firstyear, @choller
|
|
|
|
|
|
|
|
- remove syntax::{help!, span_help!, span_note!}
- remove unused syntax::{struct_span_fatal, struct_span_err_or_warn!, span_err_or_warn!}
- lintify check_for_bindings_named_same_as_variants + conflicting_repr_hints
- inline syntax::{struct_span_warn!, diagnostic_used!}
- stringify_error_code! -> error_code! & use it more.
- find_plugin_registrar: de-fatalize an error
- de-fatalize metadata errors
- move type_error_struct! to rustc_typeck
- struct_span_err! -> rustc_errors
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add options to --extern flag.
This changes the `--extern` flag so that it can take a series of options that changes its behavior. The general syntax is `[opts ':'] name ['=' path]` where `opts` is a comma separated list of options. Two options are supported, `priv` which replaces `--extern-private` and `noprelude` which avoids adding the crate to the extern prelude.
```text
--extern priv:mylib=/path/to/libmylib.rlib
--extern noprelude:alloc=/path/to/liballoc.rlib
```
`noprelude` is to be used by Cargo's build-std feature in order to use `--extern` to reference standard library crates.
This also includes a second commit which adds the `aux-crate` directive to compiletest. I can split this off into a separate PR if desired, but it helps with defining these kinds of tests. It is based on #54020, and can be used in the future to replace and simplify some of the Makefile tests.
|
|
|
|
|
|
|
|
|
|
Namely, `update_extern_crate`.
Also, stop tracking visited crates in `update_extern_crate`, the rank check does the same thing (prevents visiting dependencies if the rank didn't change), but more precisely.
|
|
|
|
|
|
After it's moved to `creader.rs`
|
|
|
