Add a way to track Rustfix UI test coverage
This came out of the first Rustfix WG meeting.
One of the goals is to enable Rustfix tests for all UI tests that
trigger lints with `MachineApplicable` suggestions. In order to do that
we first want to create a tracking issue that lists all files with
missing `// run-rustfix` headers.
This PR adds a `--rustfix-coverage` flag to `./x.py` and compiletest to
list the files with the missing headers in `/tmp/rustfix_missing_coverage.txt`.
From that file we can create the tracking issue and at some point also
enforce the `// run-rustfix` flag on UI tests with `MachineApplicable`
lints.
rustc: Allow using `clang` for wasm32 targets
This commit adds support code for using `clang` directly to link the
wasm32-unknown-unknown target. Currently the target is only really
configured to link with LLD directly, but this ensures that `clang` can
be configured as well.
While not immediately useful in the near term it's likely that more
wasm32 targets will pop up over time with Clang's new native support for
WebAssembly in the 8.0.0 release. Getting support into rustc early
should make it easier to experiment with these targets and try out
various changes here and there.
rustc: Update linker flavor inference from filename
This commit fixes what is believed to be a preexisting bug in the linker
flavor inference and additionally adds a new features. Previously if the
linker didn't end in `exe` the entire file name was compared to infer
the linker's flavor. This commit fixes the code to instead
unconditionally inspect `file_stem()` which is the relevant part we're
looking at to figure out what the linker flavor is.
Additionally this commit now also adds recognition of `clang` and clang
wrappers that end in `-clang` (which look like gcc wrappers). This
should allow clang-specific wrappers to get correctly inferred to the
`Gcc` linker flavor rather than the default linker flavor configured for
a target.
Type dependent defs wrappers
First of all, forgive me if something would seem lame to you or I offend some rule (although I tried to read through docs), this is my first PR.
Issue: https://github.com/rust-lang/rust/issues/59094
This PR adds 3 helper methods to `TypeckTables`:
* `opt_type_dependent_def`
* `opt_type_dependent_def_id`
* `type_dependent_def_id`
I didn't add `type_dependent_def` as was proposed in the issue simply because it wasn't used anywhere in the code. Only non-option wrapped`type_dependent_defs()[]` accesses were found in clippy which always called `def_id()` on result.
Speaking of clippy, should I open separate PR in its own repo, given it's used as submodule here?
Sry it took me so long, as I said I'm new here and I had tough week :).
Combine input and eval_always query types
Hardcoding `Krate` as a dependency of `eval_always` queries doesn't really make sense if we want to use the query system before HIR lowering / hashing. Without that hardcoding they become pretty much identical to `input` queries, so I combined them to a single type. This will regress the `clean` incremental scenario, but that isn't terribly common.
r? @michaelwoerister
Add FromStr impl for NonZero types
This is a WIP implementation because I do have some questions regarding the solution.
Somebody should ping the lang team on this I guess.
Please see the annotations on the code for more details.
Closes#58604
Review feedback asked for the test to be generalized to include macros
2.0; that generalization is dyn-2015-idents-in-decl-macros-unlinted.rs
As a drive-by, I also decided to revise the test to make it clear
*why* we cannot generally lint these cases. (I already had similar
demonstrations in dyn-2015-edition-keyword-ident-lint.rs, but it does
not hurt to try to emphasize matters.)
I also added some commentary on the cases where we could choose to
make the lint smarter, namely the situations where a macro is
*definitely* using `dyn` as an identifier (because it is using it as a
path component).
Back-story: After reflection this morning, I realized that the
previous form of this test would allow the macro invocation to treat
the `dyn` input as a raw-identifier rather than a keyword, and since
the input was discarded by that version of the macro, the test would
pass despite the detail that the input `dyn` should not have been
parsed as a raw-identifier.
This revision fixes that oversight, by actually *using* the macro
input to construct a `Box<dyn Trait>` type.
Rollup of 12 pull requests
Successful merges:
- #57987 (Fix some AArch64 typos)
- #58581 (Refactor generic parameter encoder functions)
- #58803 (fs::copy() unix: set file mode early)
- #58848 (Prevent cache issues on version updates)
- #59198 (Do not complain about unmentioned fields in recovered patterns)
- #59351 (Include llvm-ar with llvm-tools component)
- #59413 (HirIdify hir::ItemId)
- #59441 (Remove the block on natvis for lld-link.)
- #59448 (Use consistent phrasing for all macro summaries)
- #59456 (Add documentation about `for` used as higher ranked trait bounds)
- #59472 (Document that `std::io::BufReader` discards contents on drop)
- #59474 (Fix link capitalization in documentation of std::io::BufWriter.)
Failed merges:
r? @ghost
Include llvm-ar with llvm-tools component
Adds the `llvm-ar` tool to the `llvm-tools` component. This is useful for [building and linking native code](https://doc.rust-lang.org/cargo/reference/build-scripts.html#case-study-building-some-native-code) in cargo build scripts without needing to use the platform specific `ar`. According to #58663 it is also useful for WASM.
`llvm-ar` is very small (~82KB), so it does not significantly increase the size of the `llvm-tools` component.
Fixes#58663
Do not complain about unmentioned fields in recovered patterns
When the parser has to recover from malformed code in a pattern, do not
complain about missing fields.
Fix#59145.
fs::copy() unix: set file mode early
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
Moves test::black_box to core::hint and fix black_box on wasm32 and asm.js
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! If that RFC ever gets merged, the API, docs,
etc. of this API will need to change. This PR just move the implementation of the
already existing API.
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways. Backwards compatibility is also why we continue to re-export
"black_box" from the "test" crate.
This PR also fixes black_box on the wasm32 target, which now supports inline assembly, and uses volatile loads on the asm.js target.
r? @Amanieu (cc @rust-lang/libs)
When two multiline span labels point at the same span, we special
case the output to avoid weird behavior:
```
foo(
_____^
|_____|
|| bar,
|| );
|| ^
||______|
|______foo
baz
```
instead showing
```
foo(
_____^
| bar,
| );
| ^
| |
|______foo
baz
```
