Compute polonius loan scopes over the region graph
In issue #117146 a loan flows into an SCC containing a placeholder, and whose representative is an existential region. Since we currently compute loan scopes by looking at SCCs and their representatives only, polonius would compute kill points for this loan here whereas NLLs would not of course.
There are a few ways to fix this:
- don't try to be efficient by doing the computation over SCCs, and simply look for free regions and placeholders in the successors of the issuing region.
- change how the SCC representatives are picked, biasing towards placeholders over existential regions. They *shouldn't* matter much, but some downstream code may subtly depend on the current scheme (though no tests fail if we do such a change). This is for unrelated reasons also the way #116891 changes the representative computation. So that PR would also fix issue #117146.
- try to remove placeholders from the main path, and contain them to a pre-pass + a post-pass kind of polonius leak check. If possible, it would fix this issue by turning an outlives constraints to a placeholder into a constraint to 'static. This should also fix the issue, as the representative would be the free region in the SCC. We want to prototype this change to see if it's possible to try to simplify the borrowck main path from having to deal with placeholders and higher-ranked subtyping 🤞.
I'd like to take advantage of fuzzing and a crater run sooner rather than later, so that we grow more confidence that the 2 models are indeed equivalent empirically. Therefore this PR implements option 1 to fix the issue now.
We can take care of efficiency later after validation, and once we implement option 3 (which could also impact option 2 and that associated PR, maybe the lack of placeholders could remove the need to change the representative computation) to traverse SCCs and their representative again.
(Or we maybe will have some kind of naive position-dependent outlives propagation by then and this code would have been changed)
Fixes#117146.
r? `@matthewjasper`
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.
rustdoc: stop preloading Source Serif 4 Bold
According to #91170, italic fonts are not preloaded because they're rarely used, but bold fonts are. This seems to be true of bold Source Code Pro and bold Fira Sans, but bold and italic Source Serif Pro seem to be equally heavily used.
This is, I assume, the result of using Fira Sans Bold and Source Code Bold headings, so you only get bold Serif text when the doc author uses strong `**` emphasis (or within certain kinds of tooltip, which shouldn't be preloaded because they only show up long after the page is loaded).
To check this, run these two commands in the browser console to measure how much they're used. The measurement is extremely rough, but it gets the idea across: the two styles are about equally popular.
// count bold elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontWeight > 400 }).length
// count italic elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontStyle == "italic" }).length
| URL | Bold | Italic |
|--------------|-----:|-------:|
| [std] | 2 | 9 |
| [Vec] | 8 | 89 |
| [regex] | 33 | 17 |
| [test_suite] | 0 | 0 |
[std]: https://doc.rust-lang.org/nightly/std/index.html
[Vec]: https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html
[regex]: https://docs.rs/regex/1.9.5/regex/index.html
[test_suite]: https://docs.rs/test-suite/3.2.9/test_suite/
Give a better diagnostic for missing parens in Fn* bounds
Fixes#108109
It would be nice to try and recover here, but I'm not sure it's worth the effort, especially as the bounds on the recovered function would be incorrect.
Thir unsafeck fixes
- Recognise thread local statics in THIR unsafeck
- Add suggestion for unsafe_op_in_unsafe_fn
- Fix unsafe checking of let expressions
Only instantiate binder during dyn's built-in trait candidate probe once
See UI test for demonstration of the issue.
This was "caused" by #117131, but only because we're using the `normalize_param_env` (which has been augmented with a projection clause used to normalize GATs) which features non-lifetime bound vars in it.
Fixes#117602 technically, though that's also fixed by #117542.
r? types
Build a better MIR body when errors are encountered
Doesn't really have much of an effect on its own, but it does lead to a less confusing phony MIR body being generated when an error is detected during THIR/MIR/match building. This was quite confusing when I hacked `-Zunpretty=mir` to emit `mir_built` rather than `instance_mir`.
This coincidentually also fixes#117413, but not as generally as #117416.
cc `@Nadrieril`
