Add `never_patterns` feature gate
This PR adds the feature gate and most basic parsing for the experimental `never_patterns` feature. See the tracking issue (https://github.com/rust-lang/rust/issues/118155) for details on the experiment.
`@scottmcm` has agreed to be my lang-team liaison for this experiment.
Update cargo
7 commits in 9b13310ca596020a737aaa47daa4ed9ff8898a2f..26333c732095d207aa05932ce863d850fb309386
2023-11-24 16:20:51 +0000 to 2023-11-28 20:07:39 +0000
- docs: link to the packages lint table from the related workspace table (rust-lang/cargo#13057)
- Add more doc comments for gc changes. (rust-lang/cargo#13055)
- docs: Provide pointers for MSRV (rust-lang/cargo#13056)
- Fixed typo in SemVer Compatibility documentation page (rust-lang/cargo#13054)
- refactor: use custom error instead of anyhow (rust-lang/cargo#13050)
- review and remove ignored tests in rustfix (rust-lang/cargo#13047)
- docs: add doc comments for rustfix (rust-lang/cargo#13048)
r? ghost
Remove HIR opkinds
`hir::BinOp`, `hir::BinOpKind`, and `hir::UnOp` are identical to `ast::BinOp`, `ast::BinOpKind`, and `ast::UnOp`, respectively. This seems silly, so this PR removes the HIR ones. (A re-export lets the AST ones be referred to using a `hir::` qualifier, which avoids renaming churn.)
r? `@cjgillot`
- Rename them both `as_str`, which is the typical name for a function
that returns a `&str`. (`to_string` is appropriate for functions
returning `String` or maybe `Cow<'a, str>`.)
- Change `UnOp::as_str` from an associated function (weird!) to a
method.
- Avoid needless `self` dereferences.
Update cargo
7 commits in 71cd3a926f0cf41eeaf9f2a7f2194b2aff85b0f6..9b13310ca596020a737aaa47daa4ed9ff8898a2f
2023-11-20 15:30:57 +0000 to 2023-11-24 16:20:51 +0000
- feat: Add `CARGO_RUSTC_CURRENT_DIR` (unstable) (rust-lang/cargo#12996)
- Exited with hard error when custom build file no existence or not in package (rust-lang/cargo#12995)
- try running on windows (rust-lang/cargo#13042)
- refactor(toml): Better abstract inheritance details (rust-lang/cargo#13021)
- cargo-test-support: Add features to the default Cargo.toml file (rust-lang/cargo#12997)
- Migrate rustfix to the cargo repo (rust-lang/cargo#13005)
- typo: rusc -> rustc (rust-lang/cargo#13019)
---
This also removes the check to ensure that `rustfix` between
* src/tools/cargo
* src/tools/compiletest
has the same version,
since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`.
r? ghost
run the provenance-gc=1 test on all targets, but only for the host tests
No need to slow down *all those tests* running on the Linux host... but lets cover each major OS at least once. We've had bugs that only some macOS-specific code in `getrandom` found, after all.
Let's see how much this affects timing on the macOS / Windows runners.
before: only on Linux host, all tests
after: only the test suite itself (not cargo-miri or the mir-opt-level=4 run),
on all hosts for the host target and on Linux for all "full" targets.
Replace `option.map(cond) == Some(true)` with `option.is_some_and(cond)`
Requested by `@fmease` in https://github.com/rust-lang/rust/pull/118226#pullrequestreview-1747432292.
There is also a much larger number of `option.map_or(false, cond)` that can be changed separately if someone wants.
r? fmease
This removes the check to ensure that `rustfix` between
* src/tools/cargo
* src/tools/compiletest
has the same version,
since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`.
Fixes error count display is different when there's only one error left
Supersedes #114759
### What did I do?
I did the small change in `rustc_errors` by hand. Then I did the other changes in `/compiler` by hand, those were just find replace on `*.rs` in the workspace. The changes in run-make are find replace for `run-make` in the workspace.
All other changes are blessed using `x test TEST --bless`. I blessed the tests that were blessed in #114759.
### how to review this nightmare
ping bors with an `r+`. You should check that my logic is sound and maybe quickly scroll through the diff, but fully verifying it seems fairly hard to impossible. I did my best to do this correctly.
Thank you `@adrianEffe` for bringing this up and your initial implementation.
cc `@flip1995,` you said you want to do a subtree sync asap
cc `@RalfJung` maybe you want to do a quick subtree sync afterwards as well for Miri
r? `@WaffleLapkin`
Update windows-bindgen and define `INVALID_HANDLE_VALUE` ourselves
We generate bindings to the Windows API via the `windows-bindgen` crate, which is ultimately what's also used to generate the `windows-sys` and `windows` crates. However, there currently is some custom sauce just for std which makes it a bit different from the vanilla bindings. I would love for us to reduce and eventually remove the differences entirely so that std is using the exact same bindings as everyone else. Maybe in the future we can even just have a normal dependency on `windows-sys`.
This PR removes one of those special things. Our definition of `INVALID_HANDLE_VALUE` relies on an experimental nightly feature for strict provenance, so lets bring that back in house. It also excludes it from the codegen step though that isn't strictly necessary as we override it in any case.
This PR also updates windows-bingen to 0.52.0.
Miri: GC the dead_alloc_map too
dead_alloc_map is the last piece of state in the interpreter I can find that leaks. With this PR, all of the long-term memory growth I can find in Miri with programs that do things like run a big `loop {` or run property tests is attributable to some data structure properties in borrow tracking, and is _extremely_ slow.
My only gripe with the commit in this PR is that I don't have a new test for it. I'd like to have a regression test for this, but it would have to be statistical I think because the peak memory of a process that Linux reports is not exactly the same run-to-run. Which means it would have to not be very sensitive to slow leaks (some guesswork suggests for acceptable CI time we would be checking for like 10% memory growth over a minute or two, which is still pretty fast IMO).
Unless someone has a better idea for how to detect a regression, I think on balance I'm fine with manually keeping an eye on the memory use situation.
r? RalfJung
detect and test for data races between setenv and getenv
But only on Unix; Windows doesn't have such a data race. Also make target_os_is_unix properly check for unix, which then makes our completely empty android files useless.
