When we switch back and forth between the old and recent branches,
if there was a breaking change in the bootstrap configuration in
between, we have to update the change-id in the build configuration
with each checkout, which can be exhausting. This change fixes that.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
coverage: Rename the `run-coverage` test mode to `coverage-run`
Follow-up to https://github.com/rust-lang/rust/pull/117484#issuecomment-1788916563.
Renaming this test mode to `coverage-run` makes it more consistent with the `coverage-map` mode and the shared `tests/coverage` test directory.
---
``@rustbot`` label +A-code-coverage
Add -Zcross-crate-inline-threshold=yes
``@thomcc`` says this would be useful for
> seeing if it makes a difference in some code if i do it when building the sysroot, since -Zbuild-std + lto helps more than it seems like it should
And I've changed the possible values as a reference to ``@Manishearth`` saying
> LLVM's inlining heuristic is "yes".
Only use `normalize_param_env` when normalizing predicate in `check_item_bounds`
Only use the `normalize_param_env` when normalizing the item bound predicate in `check_item_bounds`, instead of using it when processing this obligation as well. This causes <BUG> to reoccur, but hopefully with better caching in the future, we can fix this would having such bad effects on perf.
This PR also fixes#117598. It turns out that the GAT predicate that we install is actually wrong -- given code like:
```
impl<'r> HasValueRef<'r> for Any {
type Database = Any;
}
```
We currently generate a predicate that looks like `<Any as HasValueRef<'r>>::Database = Any`, where `'r` is an early-bound variable. Really this GAT assumption should be universally quantified over the impl's args, i.e. `for<'r> <Any as HasValueRef<'r>>::Database = Any`, but then we'd need the binder to also include all the WC of the impl as well, which we don't support yet, lol.
Add a new `download-ci-llvm = if-unchanged` option and enable it by default for `profile = codegen`
Three tasks have been implemented here.
Add a new `download-ci-llvm = if-unchange` option and enable if by
default for `profile = codegen`.
Include all build artifacts by traversing the llvm-project build output,
Keep the downloadable llvm the same state as if you have just run a full
source build.
After selecting the codegen profile during ./x.py setup, the submodule
will be automatically downloaded.
Resolves#110087
Update cargo
7 commits in 65e297d1ec0dee1a74800efe600b8dc163bcf5db..7046d992f9f32ba209a8079f662ebccf9da8de25
2023-11-03 20:56:31 +0000 to 2023-11-08 03:24:57 +0000
- fix: Report more detailed semver errors (rust-lang/cargo#12924)
- Fix some broken links in the man pages (rust-lang/cargo#12929)
- Add better error message when it can not find the search section (rust-lang/cargo#12865)
- Bug 12920 (rust-lang/cargo#12923)
- Update link in environment-variables.md (rust-lang/cargo#12922)
- refactor(toml): Pull out the schema (rust-lang/cargo#12911)
- tests: Remove plugin tests (rust-lang/cargo#12921)
r? ghost
To avoid `!matches!(...)`, which is hard to think about. Instead every
case now uses direct pattern matching and returns true or false.
Also add a couple of cases to the `stringify.rs` test that currently
print badly.
coverage: Unify `tests/coverage-map` and `tests/run-coverage` into `tests/coverage`
Ever since the introduction of the `coverage-map` suite, it's been awkward to have to manage two separate coverage test directories containing dozens of mostly-identical files.
However, those two suites were separate for good reasons. They have very different requirements (since only one of them requires actually running the test program), running only one suite is noticeably faster than running both, and having separate suites allows them to be blessed separately if desired. So while unifying them was an obvious idea, actually doing so was non-trivial.
---
Nevertheless, this PR finds a way to merge the two suites into one directory while retaining almost all of the developer-experience benefits of having two suites. This required non-trivial implementations of `Step`, but the end result works very smoothly.
---
The first 5 commits are a copy of #117340, which has been closed in favour of this PR.
Three tasks have been implemented here.
Add a new `download-ci-llvm = if-unchange` option and enable if by
default for `profile = codegen`.
Include all build artifacts by traversing the llvm-project build output,
Keep the downloadable llvm the same state as if you have just run a full
source build.
After selecting the codegen profile during ./x.py setup, the submodule
will be automatically downloaded.
Method suggestion code tweaks
I was rummaging around the method suggestion code after https://github.com/rust-lang/rust/pull/117006#discussion_r1384153722 and saw a few things to simplify.
This is two unrelated commits, both in the same file. Review them separately, if you'd like.
r? estebank
Fix some clippy perf lints
`@matthiaskrgr` gave me the output of a clippy run with perf lints enabled. This PR fixes ones that I thought were worth fixing.
r? `@cuviper`
ci: bump gcc on dist x64 linux builder to 9.5
Support for `-fuse-ld=lld` was added in GCC 9, so this PR bumps gcc to the latest 9.x release, to prepare for switching to LLD.
`-Clinker-flavor=gnu-lld-cc -Clink-self-contained=+linker` will require our CI's GCC to understand `-fuse-ld=lld` when bootstrapping in a future where `x86_64-unknown-linux-gnu` is using `rust-lld` by default.
llvm-wrapper: Remove include of non-existant Vectorize.h
LLVM recently removed the header: 2400c54c37
It only contained a declaration of `createLoadStoreVectorizerPass()`, which Rust doesn't reference.
Update books
## rust-lang/reference
4 commits in 16fd3c06d9e558dae2d52000818274ae70c9e90a..cd8193e972f61b92117095fc73b67af767b4d6bc
2023-11-04 17:19:39 UTC to 2023-10-30 16:04:52 UTC
- Guarantee that raw pointer conversions preserve slice element count (rust-lang/reference#1417)
- some asm block flags also mean there can be no fences (rust-lang/reference#1413)
- Guarantee `char` layout (rust-lang/reference#1401)
- Doc: Add the RISC-V stabilized target features (rust-lang/reference#1415)
## rust-lang/rust-by-example
3 commits in 6709beeb7d0fbc5ffc91ac4893a24434123b9bfa..311b84962016b28c75525c86e7b3f49fd9101a39
2023-10-31 18:32:09 UTC to 2023-10-31 18:30:39 UTC
- Fixed explanation mistake in comment (rust-lang/rust-by-example#1761)
- Fix typos (rust-lang/rust-by-example#1759)
- docs(9.2): fix typo (rust-lang/rust-by-example#1754)
## rust-lang/rustc-dev-guide
6 commits in b0ee9ec8fa59a6c7620165e061f4747202377a62..77dbe5782b2488af3bb489ad702eaff438f465bf
2023-11-06 16:14:34 UTC to 2023-10-29 17:16:02 UTC
- add a new type system invariant (rust-lang/rustc-dev-guide#1822)
- Update some outdated descriptions of coverage instrumentation (rust-lang/rustc-dev-guide#1809)
- Add some documentation for unsizing (rust-lang/rustc-dev-guide#1817)
- Bibliography: fixing author of "You Can't Spell Trust Without Rust" (rust-lang/rustc-dev-guide#1815)
- remove change-id from sample build configuration (rust-lang/rustc-dev-guide#1813)
- Update name of "active" features to "unstable" (rust-lang/rustc-dev-guide#1814)
warn when using an unstable feature with -Ctarget-feature
Setting or unsetting the wrong target features can cause ABI incompatibility (https://github.com/rust-lang/rust/issues/116344, https://github.com/rust-lang/rust/issues/116558). We need to carefully audit features for their ABI impact before stabilization. I just learned that we currently accept arbitrary unstable features on stable and if they are in the list of Rust target features, even unstable, then we don't even warn about that!1 That doesn't seem great, so I propose we introduce a warning here.
This has an obvious loophole via `-Ctarget-cpu`. I'm not sure how to best deal with that, but it seems better to fix what we can and think about the other cases later, maybe once we have a better idea for how to resolve the general mess that are ABI-affecting target features.
