Avoid accidentally enabling unstable features in compilers (take 2)
This allows rustbuild to control whether crates can use nightly features or not.
It also prevents rustbuild from using nightly features itself.
This is #92261, but I fixed the CI error.
Do leak check after function pointer coercion
cc #73154
I still need to clean diagnostics just a tad, but figured I would put this up anyways.
This change is made in order to make match arm coercion order-independent.
Basically, any time we do function pointer coercion, we follow it by doing a leak check. This is necessary because the LUB code doesn't handler higher-ranked things correctly, leading us to "coerce", but use the wrong type. A proper fix is to actually fix that code (so the type returned by `unify_and` is a supertype of both `a` and `b` if `Ok`). However, that requires a more in-depth fix, likely heavily overlapping with the new subtyping changes.
Here, I've been conservative and error early if we generate unsatisfiable constraints. Note, this should *mostly* only affect NLL, since migrate mode falls back to the LUB implementation (followed by leak check), whereas NLL only does sub.
There could be other coercion code that has an order-dependence where a leak check in the coercion code might be useful. However, this is more of a spot-fix for #73154 than a "permanent" fix, since we likely want to go the other way long-term, and allow this pattern without error.
r? `@nikomatsakis`
Move the extended lifetime resolution into typeck context
Related to #15023
This PR is based on the [idea](https://github.com/rust-lang/rust/issues/15023#issuecomment-1070931433) of #15023 by `@nikomatsakis.`
This PR specifically proposes to
- Delay the resolution of scopes of rvalues to a later stage, so that enough type information is available to refine those scopes based on relationships of lifetimes.
- Highlight relevant parts that would help future reviews on the next installments of works to fully implement a solution to RFC 66.
Implement proper stability check for const impl Trait, fall back to unstable const when undeclared
Continuation of #93960
`@jhpratt` it looks to me like the test was simply not testing for the failure you were looking for? Your checks actually do the right thing for const traits?
Omit stdarch workspace from rust-src
The path `library/stdarch/crates/Cargo.toml` does not exist.
In Rust 1.61.0, `rust-src` still includes `src/rust/library/stdarch/Cargo.toml` (but not `stdarch-verify`), which includes
```toml
[workspace]
members = [
"crates/stdarch-verify"
```
This didn't show up when testing with `-Zbuild-std` in https://github.com/rust-lang/rust/pull/94907 since the [standard list of crates](f624095e1c/src/cargo/core/compiler/standard_lib.rs (L26-L30)) to include when building `std` does not include `stdarch`, but it will show up if a user explicitly requests `stdarch`. Or, perhaps more importantly, because of https://github.com/rust-lang/rust/issues/95736, many editors (like IntelliJ) won't treat the root of `rust-src` as a workspace, and will instead recurse into all the sub-crates directly, which then includes `stdarch`.
Also related to https://github.com/rust-lang/rust/issues/94906.
correctly deal with user type ascriptions in pat
supersedes #93856
`thir::PatKind::AscribeUserType` previously resulted in `CanonicalUserTypeAnnotations` where the inferred type already had a subtyping relation according to `variance` to the `user_ty`.
The bug can pretty much be summarized as follows:
- during mir building
- `user_ty -> inferred_ty`: considers variance
- `StatementKind::AscribeUserType`: `inferred_ty` is the type of the place, so no variance needed
- during mir borrowck
- `user_ty -> inferred_ty`: does not consider variance
- `StatementKind::AscribeUserType`: applies variance
This mostly worked fine. The lifetimes in `inferred_ty` were only bound by its relation to `user_ty` and to the `place` of `StatementKind::AscribeUserType`, so it doesn't matter where exactly the subtyping happens.
It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors.
cc #96514 which is pretty much the same issue
r? `@nikomatsakis`
Rollup of 7 pull requests
Successful merges:
- #97190 (Add implicit call to from_str via parse in documentation)
- #97218 (Add eslint checks)
- #97219 (make ptr::invalid not the same as a regular int2ptr cast)
- #97223 (Remove quadratic behaviour from -Zunpretty=hir-tree.)
- #97232 (typo)
- #97237 (Add some more weird-exprs)
- #97238 (Bump LLVM fetched from CI to fix run-make)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Bump LLVM fetched from CI to fix run-make
cc `@yaahc,` who found this while testing locally
Ideally we'd detect this in CI and catch it, but at least we have a comment now which should hopefully prevent this from happening in the future.
r? `@pietroalbini` or `@jyn514`
Add some more weird-exprs
Continuing from https://github.com/rust-lang/rust/pull/86713 (which stalled due to a thinking emoji), I'd like to "improve" the `weird-exprs.rs`-file (as I can't reopen that PR).
Add eslint checks
The first check is to ensure that `=>` is always surrounded with whitespaces.
The second is to ensure that the dict objects looks like this: `{"a": 2}` and not `{"a" : 2}` or `{"a":2}`.
r? ``@notriddle``
rustdoc: Reduce clean::Type size
There is no need to keep the `DefId` around since it's allow used to compute if we should show a cast or not. As such, we can simply directly store the boolean.
I think it's not what you had in mind `@camelid` but I guess it's still an improvement? 😉
It was discussed in https://github.com/rust-lang/rust/pull/93941.
r? `@camelid`
Remove `crate` visibility modifier
FCP to remove this syntax is just about complete in #53120. Once it completes, this should be merged ASAP to avoid merge conflicts.
The first two commits remove usage of the feature in this repository, while the last removes the feature itself.
Drop Tracking: Implement `fake_read` callback
This PR updates drop tracking's use of `ExprUseVisitor` so that we treat `fake_read` events as borrows. Without doing this, we were not handling match expressions correctly, which showed up as a breakage in the `addassign-yield.rs` test. We did not previously notice this because we still had rather large temporary scopes that we held borrows for, which changed in #94309.
This PR also includes a variant of the `addassign-yield.rs` test case to make sure we continue to have correct behavior here with drop tracking.
r? `@nikomatsakis`
Do not emit the lint `unused_attributes` for *inherent* `#[doc(hidden)]` associated items
Fixes#97205 (embarrassing oversight from #96008).
`@rustbot` label A-lint
Minor tweaks to rustc book summary formatting.
This includes a few minor tweaks to the summary/titles of chapters for the rustc book:
* Use a consistent chapter capitalization and hyphenation.
* Move "Codegen Options" underneath "Command-line Arguments". I feel like they are two closely related chapters, where codegen is just a subset of the total arguments.
* Move "Target Tier Policy" underneath "Platform Support". That chapter includes that policy for platform support, and thus I feel it is more closely related to that grouping.