build: Remove unnecessary `cargo:rerun-if-env-changed` annotations
... and a couple of related cleanups.
rustc and cargo now track the majority of env var dependencies automatically (https://github.com/rust-lang/cargo/pull/8421), so the annotations are no longer necessary.
Disable polymorphisation
Fixes#74614.
This PR disables polymorphisation to fix the regression in #74614 after investigation into the issue makes it clear that the fix won't be trivial. ~~I'll file an issue shortly to replace #74614 with the findings so far.~~ #74636 has been filed to track the fix of the underlying regression.
r? @eddyb
Stabilize control-flow-guard codegen option
This is the stabilization PR discussed in #68793. It converts the `-Z control-flow-guard` debugging option into a codegen option (`-C control-flow-guard`), and changes the associated tests.
This commit disables polymorphisation to resolve regressions related to
closures which inherit unused generic parameters and are then used in
casts or reflection.
Signed-off-by: David Wood <david@davidtw.co>
This commit replaces the `-Z polymorphize-errors` debugging flag with a
`#[rustc_polymorphize_error]` attribute for use on functions.
Signed-off-by: David Wood <david@davidtw.co>
This commit implements the `unused_generic_params` query, an initial
version of polymorphization which detects when an item does not use
generic parameters and is being needlessly monomorphized as a result.
Signed-off-by: David Wood <david@davidtw.co>
Note that the output of `unpretty-debug.stdout` has changed. In that
test the hash values are normalized from a symbol numbers to small
numbers like "0#0" and "0#1". The increase in the number of static
symbols must have caused the original numbers to contain more digits,
resulting in different pretty-printing prior to normalization.
Rollup of 10 pull requests
Successful merges:
- #73414 (Implement `slice_strip` feature)
- #73564 (linker: Create GNU_EH_FRAME header by default when producing ELFs)
- #73622 (Deny unsafe ops in unsafe fns in libcore)
- #73684 (add spans to injected coverage counters, extract with CoverageData query)
- #73812 (ast_pretty: Pass some token streams and trees by reference)
- #73853 (Add newline to rustc MultiSpan docs)
- #73883 (Compile rustdoc less often.)
- #73885 (Fix wasm32 being broken due to a NodeJS version bump)
- #73903 (Changes required for rustc/cargo to build for iOS targets)
- #73938 (Optimise fast path of checked_ops with `unlikely`)
Failed merges:
r? @ghost
added regions with counter expressions and counters.
Added codegen_llvm/coverageinfo mod for upcoming coverage map
Move coverage region collection to CodegenCx finalization
Moved from `query coverageinfo` (renamed from `query coverage_data`),
as discussed in the PR at:
https://github.com/rust-lang/rust/pull/73684#issuecomment-649882503
Address merge conflict in MIR instrument_coverage test
The MIR test output format changed for int types.
moved debug messages out of block.rs
This makes the block.rs calls to add coverage mapping data to the
CodegenCx much more concise and readable.
move coverage intrinsic handling into llvm impl
I realized that having half of the coverage intrinsic handling in
`rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any
non-llvm backend would be bound to the same decisions about how the
coverage-related MIR terminators should be handled.
To fix this, I moved the non-codegen portion of coverage intrinsic
handling into its own trait, and implemented it in `rustc_codegen_llvm`
alongside `codegen_intrinsic_call`.
I also added the (required?) stubs for the new intrinsics to
`IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do
not fail if called with these new but known intrinsics.
address PR Feedback on 28 June 2020 2:48pm PDT
Implement mixed script confusable lint.
This implements the mixed script confusable lint defined in RFC 2457.
This is blocked on #72069 and https://github.com/unicode-rs/unicode-security/pull/13, and will need a Cargo.toml version bump after those are resolved.
The lint message warning is sub-optimal for now. We'll need a mechanism to properly output `AugmentScriptSet` to screen, this is to be added in `unicode-security` crate.
r? @Manishearth
Self contained linking option
With objects moved to self-contained directory by https://github.com/rust-lang/rust/pull/72999 we can now add option to control whether to use self-contained on native linkage mode.
Print environment variables accessed by rustc as special comments into depinfo files
So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes.
---
I've recently observed one more forgotten environment variable in a build script 8a77d1ca3f and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo.
Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517https://github.com/rust-lang/rust/issues/40364https://github.com/rust-lang/rust/issues/44074.
Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts.
---
Description:
- depinfo files are extended with special comments containing info about environment variables accessed during compilation.
- Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`.
- Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`).
- `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends.
FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488
Closes https://github.com/rust-lang/rust/issues/70517
Closes https://github.com/rust-lang/rust/issues/40364
Closes https://github.com/rust-lang/rust/issues/44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.
r? @ehuss
Fix -Z unpretty=everybody_loops
It turns out that this has not been working for who knows how long.
Previously:
```
pub fn h() { 1 + 2; }
```
After this change:
```
pub fn h() { loop { } }
```
This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
code coverage foundation for hash and num_counters
This PR is the next iteration after PR #73011 (which is still waiting on bors to merge).
@wesleywiser - PTAL
r? @tmandry
(FYI, I'm also working on injecting the coverage maps, in another branch, while waiting for these to merge.)
Thanks!
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
It turns out that this has not been working for who knows how long.
Previously:
```
pub fn h() { 1 + 2; }
```
After this change:
```
pub fn h() { loop {} }
```
This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
Replaced dummy values for hash and num_counters with computed values,
and refactored InstrumentCoverage pass to simplify injecting more
counters per function in upcoming versions.
Improved usage documentation and error messaging.
Implement crate-level-only lints checking.
This implements a crate_level_only flag on lints, and when it is true, it becomes an error when user tries to specify this flag upon nodes other than crate node.
This also turns on this flag for all non_ascii_ident lints.
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.](cfa0b21d34/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
Create self-contained directory and move there some of external binaries/libs
One of the steps to reach design described in https://github.com/rust-lang/rust/issues/68887#issuecomment-633048380
This PR moves things around and allows link code to handle the new directory structure.
This initial version only injects counters at the top of each function.
Rust Coverage will require injecting additional counters at each
conditional code branch.
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
expand: More precise locations for expansion-time lints
First commit: a macro expansion doesn't have a `NodeId` associated with it, but it has a parent `DefId` which we can use for linting.
The observable effect is that lints associated with macro expansions can now be `allow`ed at finer-grained level than whole crate.
Second commit: each macro definition has a `NodeId` which we can use for linting, unless that macro definition was decoded from other crate.
Add `-Z span-debug` to allow for easier debugging of proc macros
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once #72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
