Add `normalize()` in run-make `Diff` type
I need it to do the same as:
```
//@ normalize-stdout-test "finished in \d+\.\d+s" -> "finished in $$TIME"
```
in doctests.
I need it in particular for the https://github.com/rust-lang/rust/pull/123974 PR (which contains this commit until this PR current PR is merged).
cc `@Urgau`
r? `@jieyouxu`
Write `git-commit-{sha,info}` for Cargo in source tarballs
Right now Cargo doesn't populate the commit hash or date in its version output when it's built from the plain source tarball. That's because we don't include the git information for it, and Cargo's build script doesn't pick it up.
This PR *partially* solves the problem by storing the git information for Cargo in `src/tools/cargo` in the plain source tarball. We store separate information because even when built in CI Cargo uses its own git information rather than Rust's.
This PR will also require a change in the Cargo repository to consume this information (https://github.com/rust-lang/cargo/pull/13832), but it doesn't have to be blocked on the Cargo PR being merged.
Add test for issue 106269
Closes#106269
Made this an assembly test as the LLVM codegen is still quite verbose and doesn't really indicate the behaviour we want
Port repr128-dwarf run-make test to rmake
This PR ports the repr128-dwarf run-make test to rmake, using the `gimli` crate instead of the `llvm-dwarfdump` command.
Note that this PR changes `rmake.rs` files to be compiled with the 2021 edition (previously no edition was passed to `rustc`, meaning they were compiled with the 2015 edition). This means that `panic!("{variable}")` will now work as expected in `rmake.rs` files (there's already a usage in the [wasm-symbols-not-exported test](aca749eefc/tests/run-make/wasm-symbols-not-exported/rmake.rs (L34)) that this will fix).
Tracking issue: #121876
Remove many `#[macro_use] extern crate foo` items
This requires the addition of more `use` items, which often make the code more verbose. But they also make the code easier to read, because `#[macro_use]` obscures where macros are defined.
r? `@fee1-dead`
Mention Both HRTB and Generic Lifetime Param in `E0637` documentation
The compiler (rustc 1.77.0) error for `and_without_explicit_lifetime()` in the erroneous code example suggests using a HRTB. But, the corrected example uses an explicit lifetime parameter.
This PR fixes it so that the documentation and the compiler suggestion for error code `E0637` are consistent with each other.
Modify lint pass note for consistency with the book
This PR:
- removes the note which appears when an early lint pass is created using `cargo dev new_lint`.
- adds a note that encourages contributors to use an early pass unless type information is needed if a late lint pass is created using `cargo dev new_lint`.
Late pass remains the default value if no pass is specified as most lints use late pass.
Closes#12595
changelog: none
coverage: Split off `mappings.rs` from `spans.rs` and `from_mir.rs`
Originally, `spans.rs` was mainly concerned with extracting and post-processing spans from MIR, so that they could be used for block coverage instrumentation.
Over time it has organically expanded to include more responsibilities, especially relating to branch coverage and MC/DC coverage, that don't really fit its current name.
This PR therefore takes all the extra code that is *not* part of the old span-refinement engine, and moves it out into a new `mappings.rs` file.
---
No functional changes. I have deliberately avoided doing any follow-up (such as renaming types or functions), because this particular change is very rot-prone, and I want it to be as simple and self-contained as possible.
`@rustbot` label +A-code-coverage
because we are already marking unions `NoPropagation` in
`CanConstProp::check()`. That is enough to prevent any attempts
at const propagating unions and this second check is not needed.
Also improve a comment in `CanConstProp::check()`
Split mcdc code to a sub module of coverageinfo
A further work from #124217 . I have made relatively large changes when working on #124278 so that it would better split them from `coverageinfo.rs` to avoid potential troubling merge work with improved branch coverage by `@Zalathar` .
Besides `BlockMarkerGenerator` is added to avoid ownership problems (mostly needed for following change of #124278 )
All code changes are done in [a37d737a](a3d737a086) while the second commit just renames the file.
cc `@RenjiSann` `@Zalathar`
This will impact your current work.
Yes it looks weird, but this is how Arm write it now.
I left ARM64 alone, because it's a Microsoft/Apple term but not an Arm term (they have Armv8-A and Armv9-A architectures, which say that A64 instructions are executed when in the Aarch64 state), and I don't want to get into that, especially for a Tier 1 target.
Explicitly document that the jobserver may be used by `rustc` and show
the warning to increase the chances that this document is found when
searching for solutions online.
In particular, add a section about the interaction with build systems,
which is intended to contain recommendations on how to integrate `rustc`
with different built systems.
For GNU Make, recommend using the `+` indicator. In addition, add a
note about the issue with GNU Make 4.3 since it is important that users
realize they should do this even if they do not expect parallelism from
`rustc`. Finally, show how to workaround the issue of `$(shell ...)`
calls in recursive Make (which e.g. was needed for the Linux kernel).
The GNU Make 4.4 case under `--jobserver-style=pipe` is not added since
it got fixed after Rust 1.76.0 already (i.e. `rustc` will not warn if
it finds the negative file descriptors).
For CMake, recommend using `JOB_SERVER_AWARE` and show a workaround using
`$(MAKE)` for earlier versions (when using the Makefile generator).
From: https://github.com/rust-lang/rust/issues/120515
Cc: @petrochenkov @belovdv @weihanglo @bjorn3
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rollup of 4 pull requests
Successful merges:
- #124519 (adapt a codegen test for llvm 19)
- #124524 (Add StaticForeignItem and use it on ForeignItemKind)
- #124540 (Give proof tree visitors the ability to instantiate nested goals directly)
- #124543 (codegen tests: Tolerate `range()` qualifications in enum tests)
r? `@ghost`
`@rustbot` modify labels: rollup
codegen tests: Tolerate `range()` qualifications in enum tests
Current LLVM can infer range bounds on the i8s involved with these tests, and annotates it. Accept these bounds if present.
`@rustbot` label: +llvm-main
cc `@durin42`
Give proof tree visitors the ability to instantiate nested goals directly
Useful when we want to look at the nested goals but not necessarily visit them (e.g. in select).
r? lcnr
Add StaticForeignItem and use it on ForeignItemKind
This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.
r? `@oli-obk`
cc `@compiler-errors`
Add StaticForeignItem and use it on ForeignItemKind
This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.
r? `@oli-obk`
cc `@compiler-errors`
coverage: Replace boolean options with a `CoverageLevel` enum
After #123409, and some discussion at https://github.com/rust-lang/rust/issues/79649#issuecomment-2042093553 and #124120, it became clear to me that we should have a unified concept of “coverage level”, instead of having several separate boolean flags that aren't actually independent.
This PR therefore introduces a `CoverageLevel` enum, to replace the existing boolean flags for `branch` and `mcdc`.
The `no-branch` value (for `-Zcoverage-options`) has been renamed to `block`, instructing the compiler to only instrument for block coverage, with no branch coverage or MD/DC instrumentation.
`@rustbot` label +A-code-coverage
cc `@ZhuUx` `@Lambdaris` `@RenjiSann`
suppress `readonly_write_lock` for underscore-prefixed bindings
Fixes#12733
Unsure if there's a better way to prevent this kind of false positive but this is the one that made most sense to me.
In my experience, prefixing bindings with an underscore is the usual way to name variables that aren't used and that exist purely for executing drop code at the end of the scope.
-------
changelog: suppress [`readonly_write_lock`] for underscore-prefixed bindings
[`type_complexity`]: Fix duplicate errors
Relates to #12379
Following message was duplicated:
```
LL | fn def_method(&self, p: Vec<Vec<Box<(u32, u32, u32, u32)>>>) {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
error: very complex type used. Consider factoring parts into `type` definitions
--> tests/ui/type_complexity.rs:55:15
```
Methods `check_trait_item` and `check_fn` were both checking method named def_method.
Now `check_trait_item` only checks methods without body.
---
changelog: [`type_complexity`]: Fix duplicate diagnostics
Add a note to the ArbitraryExpressionInPattern error
The current "arbitrary expressions aren't allowed in patterns" error is confusing, as it fires for code where it *looks* like a pattern but the compiler still treats it as an expression. That this is due to the `:expr` fragment specifier forcing the expression-ness property on the code.
In the test suite, the "arbitrary expressions aren't allowed in patterns" error can only be found in combination with macro_rules macros that force expression-ness of their content, namely via `:expr` metavariables. I also can't come up with cases where there would be an expression instead of a pattern, so I think it's always coming from an `:expr`.
In order to make the error less confusing, this adds a note explaining the weird `:expr` fragment behaviour.
Fixes#99380
Remove optionality from MoveData::base_local
This is an artifact from when Places could be based on statics and not just locals. Now, all move paths either are locals or have parents, so this doesn't need to return Option anymore.
clippy::single_match(_else) may be machine applicable
```
changelog: [`single_match`]: make the lint machine-applicable
changelog: [`single_match_else`]: make the lint machine-applicable
```
---
The lint doesn't use placeholders. I've tried it on my codebases, and all instances of it applied without problems.
