This is a workaround for #122758, but it's not clear why 1.79 requires a
more extensive amount of no_inline than the previous release. Seems like
there's something relatively subtle happening here.
Rewrite select (in the new solver) to use a `ProofTreeVisitor`
We can use a proof tree visitor rather than collecting and recomputing all the nested goals ourselves.
Based on #124415
There are a few tests that depend on some target features **not** being
enabled by default, and usually they are correct with the default x86-64
target CPU. However, in downstream builds we have modified the default
to fit our distros -- `x86-64-v2` in RHEL 9 and `x86-64-v3` in RHEL 10
-- and the latter especially trips tests that expect not to have AVX.
These cases are few enough that we can just set them back explicitly.
Arm bare-metal target doc changes
Updates the Arm bare-metal target docs:
* Detailed pages for all the Cortex-M targets, including details about setting target-cpu and target-features to suit specific Arm models
* More detail about the difference between `eabi` and `eabihf`
* Marks the Embedded Devices Working Group Cortex-M Team as the maintainer of the Cortex-M targets
Don’t print `Preparing a sysroot` when `-q`/`--quiet` is passed
Resolves#3530.
This also fixes a typo in `cargo miri --help` that I found while trying to run the `--print-sysroot` example.
rustc: document the jobserver
Explicitly document that the jobserver may be used by `rustc`, as well as recommend the `+` indicator for integration of `rustc` into GNU Make.
In particular, show the warning to increase the chances that this document is found when searching for solutions online.
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).
From: https://github.com/rust-lang/rust/issues/120515
Cc: `@petrochenkov` `@belovdv` `@weihanglo` `@bjorn3`
---
v2: To be able to use tab characters for the Make examples, add `<!-- ignore-tidy-{check} -->` support to `tidy`.
v3: Added "Integration with build systems" section to hold the GNU Make one. Added "by clearing the `MAKEFLAGS` variable". Added "aforementioned" so that it is clear we are talking about the warning above.
v4: Added CMake subsection. Added a note that `rustc` may be affected by other flags, e.g. `CARGO_MAKEFLAGS`.
v5: Added that `rustc` will choose the number of jobs if a jobserver is not passed.
fix suggestion error for [`manual_is_ascii_check`] with missing type
fixes: #11324fixes: #11776
changelog: improve [`manual_is_ascii_check`] to suggest labeling type in closure, fix FP with type generics, and improve linting on ref expressions.
Update cargo
15 commits in b60a1555155111e962018007a6d0ef85207db463..6087566b3fa73bfda29702632493e938b12d19e5
2024-04-26 16:37:29 +0000 to 2024-04-30 20:45:20 +0000
- fix(cargo-fix): dont fix into standard library (rust-lang/cargo#13792)
- refactor: Move diagnostic printing to Shell (rust-lang/cargo#13813)
- Populate git information when building Cargo from Rust's source tarball (rust-lang/cargo#13832)
- docs: fix several typos found by `typos-cli` (rust-lang/cargo#13831)
- fix(alias): Aliases without subcommands should not panic (rust-lang/cargo#13819)
- fix(toml): Improve granularity of traces (rust-lang/cargo#13830)
- fix(toml): Warn, rather than fail publish, if a target is excluded (rust-lang/cargo#13713)
- test(cargo-lints): Add a test to ensure cap-lints works (rust-lang/cargo#13829)
- fix(toml)!: Remove support for inheriting badges (rust-lang/cargo#13788)
- chore(ci): Don't check `cargo` against beta channel (rust-lang/cargo#13827)
- Fix target entry in .gitignore (rust-lang/cargo#13817)
- Bump to 0.81.0; update changelog (rust-lang/cargo#13823)
- Add failing test: artifact_dep_target_specified (rust-lang/cargo#13816)
- fix(cargo-lints): Don't always inherit workspace lints (rust-lang/cargo#13812)
- Update SleepTraker returns_in_order unit test (rust-lang/cargo#13811)
r? ghost
Use `target_vendor = "apple"` instead of `target_os = "..."`
Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.
The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](https://github.com/rust-lang/rust/issues/100343), but not before an alternative (like `target_family = "apple"`) is available.
While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: https://github.com/rust-lang/rust/pull/124494
Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee
CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful
**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:
> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.
I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?
The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.
Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.
r? lcnr or compiler
Lazily normalize inside trait ref during orphan check & consider ty params in rigid alias types to be uncovered
Fixes#99554, fixesrust-lang/types-team#104.
Fixes#114061.
Supersedes #100555.
Tracking issue for the future compatibility lint: #124559.
r? lcnr
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
