Remove support for alias `-Z instrument-coverage`
This flag was stabilized in rustc 1.60.0 (2022-04-07) as `-C instrument-coverage`, but the old unstable flag was kept around (with a warning) as an alias to ease migration.
It should now be reasonable to remove the somewhat tricky code that implemented that alias.
Fixes#116980.
Remove fold code and add `Const::internal()` to StableMIR
We are not planning to support user generated constant in the foreseeable future, so we are cleaning up the fold logic and user created type for now. Users should use `Instance::resolve` in order to trigger monomorphization.
The Instance::resolve was however incomplete, since we weren't handling internalizing constants yet. Thus, I added that.
I decided to keep the `Const` fields private in case we decide to translate them lazily.
Modernize rustc_builtin_macros generics helpers
- Rustfmt-compatible formatting for the code snippets in comments
- Eliminate an _"Extra scope required"_ obsoleted by NLL
Uplift `ClauseKind` and `PredicateKind` into `rustc_type_ir`
Uplift `ClauseKind` and `PredicateKind` into `rustc_type_ir`.
Blocked on #116951
r? `@ghost`
Get rid of `'tcx` lifetime on `ConstVid`, `EffectVid`
These are simply newtyped numbers, so don't really have a reason (per se) to have a lifetime -- `TyVid` and `RegionVid` do not, for example.
The only consequence of this is that we need to use a new key type for `UnifyKey` that mentions `'tcx`. This is already done for `RegionVid`, with `RegionVidKey<'tcx>`, but this `UnifyKey` trait implementation may have been the original reason to give `ConstVid` a lifetime. See the changes to `compiler/rustc_middle/src/infer/unify_key.rs` specifically.
I consider the code cleaner this way, though -- we removed quite a few unnecessary `'tcx` in the process. This also makes it easier to uplift these two ids to `rustc_type_ir`, which I plan on doing in a follow-up PR.
r? `@BoxyUwU`
We are not planning to support user generated constant in the
foreseeable future, so we are removing the Fold logic for now in
favor of the Instance::resolve logic.
The Instance::resolve was however incomplete, since we weren't handling
internalizing constants yet. Thus, I added that.
I decided to keep the Const fields private in case we decide to
translate them lazily.
Add method to convert internal to stable constructs
This is an alternative implementation to https://github.com/rust-lang/rust/pull/116999. I believe we can still improve the logic a bit here, but I wanted to see which direction we should go first.
In this implementation, the API is simpler and we keep Tables somewhat private. The definition is still public though, since we have to expose the Stable trait. However, there's a cost of keeping another thread-local and using `Rc`, but I'm hoping it will be a small cost.
r? ``@oli-obk``
r? ``@spastorino``
Suggest unwrap/expect for let binding type mismatch
Found it when investigating https://github.com/rust-lang/rust/issues/116738
I'm not sure whether it's a good style to suggest `unwrap`, seems it's may helpful for newcomers.
#116738 needs another fix to improve it.
Avoid unnecessary renumbering during borrowck
Currently, after renumbering there are always unused `RegionVid`s if the return type contains any regions, this is due to `visit_ty` being called twice on the same `Ty`: once with `TyContext::ReturnTy` and once with `TyContext::LocalDecl { local: _0 }`. This PR skips renumbering the first time around.
Derive `Ord`, `PartialOrd` and `Hash` for `SocketAddr*`
Fixes#116711
The main pain of this PR is to fix the buggy impl of `Ord` for `SocketAddrV6`, which ignored half of the fields (while `PartialEq` is derived):
4603f0b8af/library/core/src/net/socket_addr.rs (L99-L106)4603f0b8af/library/core/src/net/socket_addr.rs (L676)
For me it looks like a simple copy-paste error made in https://github.com/rust-lang/rust/pull/72239 (copy from v4 impl) (cc `@hch12907),` as I don't see this behavior being mentioned anywhere on the PR and it also does not respect `cmp` trait "rules". I also do not see any reasons for those impls to _not_ be derived.
It's a shame we did not notice this for 28 versions/3 years. I guess this is a bug fix, but I'm not sure what the process here should be.
r? libs
Introduce `-C instrument-coverage=branch` to gate branch coverage
This was extracted from https://github.com/rust-lang/rust/pull/115061 and can land independently from other coverage related work.
The flag is unused for now, but is added in advance of adding branch coverage support.
It is an unstable, nightly only flag that needs to be used in combination with `-Zunstable-options`, like so: `-Zunstable-options -C instrument-coverage=branch`.
The goal is to develop branch coverage as an unstable opt-in feature first, before it matures and can be turned on by default.
remove change-id assertion in bootstrap test
In the bootstrap test, the assertion of the change-id fails whenever we update the change-id next to a breaking change in build configurations. This commit removes the assertion, as it's not critical or useful to have.
ref https://github.com/rust-lang/rust/pull/115898#issuecomment-1775909050
Update books
## rust-lang/book
1 commits in 72187f5cd0beaaa9c6f584156bcd88f921871e83..3dca2fc50b922a8efb94903b9fee8bb42ab48f38
2023-10-19 18:01:47 UTC to 2023-10-19 18:01:47 UTC
- Fix cargo doc links (rust-lang/book#3751)
## rust-embedded/book
1 commits in eac173690b8cc99094e1d88bd49dd61127fbd285..22bca3d0f6e9b9b556689b54ce96f25b46ecd1b3
2023-10-16 22:47:38 UTC to 2023-10-16 22:47:38 UTC
- Improved hardware.md chapter. (rust-embedded/book#361)
## rust-lang/nomicon
1 commits in ddfa4214487686e91b21aa29afb972c08a8f0d5b..1842257814919fa62e81bdecd5e8f95be2839dbb
2023-10-17 15:11:58 UTC to 2023-10-17 15:11:58 UTC
- Fixed `Hole::get` marked as unsafe in `exception-safety.md` (rust-lang/nomicon#427)
## rust-lang/reference
2 commits in 142b2ed77d33f37a9973772bd95e6144ed9dce43..16fd3c06d9e558dae2d52000818274ae70c9e90a
2023-10-14 22:31:04 UTC to 2023-10-11 15:35:55 UTC
- Adjust reference for return-position `impl Trait` in trait and `async fn` in trait (rust-lang/reference#1409)
- Fix temporary drop scope for last expression. (rust-lang/reference#1416)
## rust-lang/rust-by-example
1 commits in 8eb3a01ab74c567b7174784892fb807f2c632d6b..6709beeb7d0fbc5ffc91ac4893a24434123b9bfa
2023-10-20 19:11:21 UTC to 2023-10-20 19:11:21 UTC
- docs: fix a typo (rust-lang/rust-by-example#1752)
## rust-lang/rustc-dev-guide
5 commits in b98af7d661e4744baab81fb8dc7a049e44a4a998..b0ee9ec8fa59a6c7620165e061f4747202377a62
2023-10-22 03:18:44 UTC to 2023-10-11 06:30:26 UTC
- Add WF to glossary (rust-lang/rustc-dev-guide#1810)
- recommend `unpretty=hir` alongside `unpretty=hir-tree` (rust-lang/rustc-dev-guide#1804)
- Start a chapter about the evolving const effect system (rust-lang/rustc-dev-guide#1808)
- Document subtle implied bounds issue in RPITIT inference (rust-lang/rustc-dev-guide#1807)
- [suggested.md] `changelog-seen` -> `change-id` in `shell.nix` (rust-lang/rustc-dev-guide#1806)
`OptWithInfcx` naming nits, trait bound simplifications
* Use an associated type `Interner` on `InferCtxtLike` to remove a redundant interner parameter (`I: Interner, Infcx: InferCtxtLike<I>` -> `Infcx: InferCtxtLike`).
* Remove double-`Option` between `infcx: Option<Infcx>` and `fn universe_of_ty(&self, ty: ty::InferTy) -> Option<ty::UniverseIndex>`. We don't need the infcx to be optional if we can provide a "noop" (`NoInfcx`) implementation that just always returns `None` for universe index.
* Also removes the `core::convert::Infallible` implementation which I found a bit weird...
* Some naming nits with params.
* I found `InferCtxt` + `InfCtx` and `Infcx` to be a lot of different ways to spell "inference context", so I got rid of the `InfCtx` type parameter name in favor of `Infcx` which is a more standard name.
* I found `OptWithInfcx` to be a bit redundant -> `WithInfcx`.
I'm making these changes because I intend to reuse the `InferCtxtLike` trait for uplifting the canonicalizer into a new trait -- conveniently, the information I need for uplifting the canonicalizer also is just the universe information of a type var, so it's super convenient 😸
r? `@BoxyUwU` or `@lcnr`
Validate `feature` and `since` values inside `#[stable(…)]`
Previously the string passed to `#[unstable(feature = "...")]` would be validated as an identifier, but not `#[stable(feature = "...")]`. In the standard library there were `stable` attributes containing the empty string, and kebab-case string, neither of which should be allowed.
Pre-existing validation of `unstable`:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![unstable(feature = "kebab-case", issue = "none")]
#[unstable(feature = "kebab-case", issue = "none")]
pub struct Struct;
```
```console
error[E0546]: 'feature' is not an identifier
--> src/lib.rs:5:1
|
5 | #![unstable(feature = "kebab-case", issue = "none")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
For an `unstable` attribute, the need for an identifier is obvious because the downstream code needs to write a `#![feature(...)]` attribute containing that identifier. `#![feature(kebab-case)]` is not valid syntax and `#![feature(kebab_case)]` would not work if that is not the name of the feature.
Having a valid identifier even in `stable` is less essential but still useful because it allows for informative diagnostic about the stabilization of a feature. Compare:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![stable(feature = "kebab-case", since = "1.0.0")]
#[stable(feature = "kebab-case", since = "1.0.0")]
pub struct Struct;
```
```rust
// src/main.rs
#![feature(kebab_case)]
use repro::Struct;
fn main() {}
```
```console
error[E0635]: unknown feature `kebab_case`
--> src/main.rs:3:12
|
3 | #![feature(kebab_case)]
| ^^^^^^^^^^
```
vs the situation if we correctly use `feature = "snake_case"` and `#![feature(snake_case)]`, as enforced by this PR:
```console
warning: the feature `snake_case` has been stable since 1.0.0 and no longer requires an attribute to enable
--> src/main.rs:3:12
|
3 | #![feature(snake_case)]
| ^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
```
Sync rustc_codegen_cranelift
This contains fixes for the last two remaining known miscompilations. One is the lack of stack alignment support in cranelift which has been worked around by dynamically realigning at runtime. This fixed rayon and by extension Wasmtime. And the other is lack of zero/sign extending of small arguments when the ABI requires this. This is completely fine when only using cg_clif compiled code, but LLVM depends on this resulting in weird behavior of mixed LLVM, Cranelift binaries. The update to Cranelift 0.101.1 fixes this. In addition I have implemented all x86_64 SIMD intrinsics required by the image and rav1e crates.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Windows: Support sub-millisecond sleep
Use `CreateWaitableTimerExW` with `CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`. Does not work before Windows 10, version 1803 so in that case we fallback to using `Sleep`.
I've created a `WaitableTimer` type so it can one day be adapted to also support waiting to an absolute time (which has been talked about). Note though that it currently returns `Err(())` because we can't do anything with the errors other than fallback to the old `Sleep`. Feel free to tell me to do errors properly. It just didn't seem worth constructing an `io::Error` if we're never going to surface it to the user. And it *should* all be infallible anyway unless the OS is too old to support it.
Closes#43376
Handle `ReErased` in responses in new solver
There are legitimate cases in the compiler where we return `ReErased` for lifetimes that are uncaptured in the hidden type of an opaque. For example, in the test committed below, we ignore ignore the bivariant lifetimes of an opaque when it's inferred as the hidden type of another opaque. This may result in a `type_of(Opaque)` call returning a type that references `ReErased`. Let's handle this gracefully in the new solver.
Also added a `rustc_hidden_type_of_opaques` attr to print hidden types. This seems useful for opaques.
r? lcnr
