add flag to dump unstable feature status information #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yaahc
force-pushed
the
unstable-feature-usage
branch
8 times, most recently
from
3cf1bb8 to
35bfeff
Compare
Fixes issue 133118. This also modifies `tests/ui/moves/moved-value-on-as-ref-arg.rs` to have more useful bounds on the tests for suggestions to borrow `Borrow` and `BorrowMut` arguments. With its old tautological `T: BorrowMut<T>` bound, this fix would make it suggest a shared borrow for that argument.
Check `use<..>` in RPITIT for refinement
`#![feature(precise_capturing_in_traits)]` allows users to write `+ use<>` bounds on RPITITs to control what lifetimes are captured by the RPITIT.
Since RPITITs currently also warn for refinement in implementations, this PR extends that refinement check for cases where we *undercapture* in an implementation, since that may be indirectly "promising" a more relaxed outlives bound than the impl author intended.
For an opaque to be refining, we need to capture *fewer* parameters than those mentioned in the captured params of the trait. For example:
```
trait TypeParam<T> {
fn test() -> impl Sized;
}
// Indirectly capturing a lifetime param through a type param substitution.
impl<'a> TypeParam<&'a ()> for i32 {
fn test() -> impl Sized + use<> {}
//~^ WARN impl trait in impl method captures fewer lifetimes than in trait
}
```
Since the opaque in the method (implicitly) captures `use<Self, T>`, and `Self = i32, T = &'a ()` in the impl, we must mention `'a` in our `use<..>` on the impl.
Tracking:
* rust-lang#130044
…-132924, r=chenyukang add parentheses when unboxing suggestion needed This PR tried to `add parentheses when unboxing suggestion needed` Fixes rust-lang#132924
…ukang Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1` Addresses rust-lang#123404 to allow test writers to specify `//@ rustc-env:RUSTC_BOOTSTRAP=-1` to have a given rustc consider itself a stable rustc. This is only intended for testing usages. I did not use `RUSTC_BOOTSTRAP=0` because that can be confusing, i.e. one might think that means "not bootstrapping", but "forcing a given rustc to consider itself a stable compiler" is a different use case. I also added a specific test to check `RUSTC_BOOTSTRAP`'s various values and how that interacts with rustc's stability story w.r.t. features and cli flags. Noticed when trying to write a test for enabling ICE file dumping on stable. Dunno if this needs a compiler FCP or MCP, but I can file an MCP or ask someone to start an FCP if needed. Note that `RUSTC_BOOTSTRAP` is a perma-unstable env var and has no stability guarantees (heh) whatsoever. This does not affect bootstrapping because bootstrap never sets `RUSTC_BOOTSTRAP=-1`. If someone does set that when bootstrapping, it is considered PEBKAC. Accompanying dev-guide PR: rust-lang/rustc-dev-guide#2136 cc `@estebank` and `@rust-lang/wg-diagnostics` for FYI
`suggest_borrow_generic_arg`: instantiate clauses properly This simplifies and fixes the way `suggest_borrow_generic_arg` instantiates callees' predicates when testing them to see if a moved argument can instead be borrowed. Previously, it would ICE if the moved argument's type included a region variable, since it was getting passed to a call of `EarlyBinder::instantiate`. This makes the instantiation much more straightforward, which also fixes the ICE. Fixes rust-lang#133118 This also modifies `tests/ui/moves/moved-value-on-as-ref-arg.rs` to have more useful bounds on the tests for suggestions to borrow `Borrow` and `BorrowMut` arguments. With its old tautological `T: BorrowMut<T>` bound, this fix would make it suggest a shared borrow for that argument.
… r=GuillaumeGomez rustdoc-search: add standalone trailing `::` test Follow up for rust-lang#132569 r? `@GuillaumeGomez`
…er-errors Diagnostics for let mut in item context The diagnostics for `let` at the top level did not account for `let mut`, which [made the error unclear](https://users.rust-lang.org/t/create-a-vector-of-constants-outside-main/121251/1). I've made the diagnostic always display a link to valid items. I've added dedicated help for `let mut` case that suggests using a `Mutex` (to steer novice users away from the `static mut` trap). Unfortunately, neither the Rust book, nor libstd docs have dedicated section listing all other types for interior-mutable `static`s.
Fixup some test directives - A random comment had somehow been turned into an `//`@`` directive. - More dubiously I also removed leading spaces from directives in 3 UI tests for consistency. These are the only rustc tests that use that formatting. r? `@jieyouxu`
Rollup of 7 pull requests Successful merges: - rust-lang#132795 (Check `use<..>` in RPITIT for refinement) - rust-lang#132944 (add parentheses when unboxing suggestion needed) - rust-lang#132993 (Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1`) - rust-lang#133130 (`suggest_borrow_generic_arg`: instantiate clauses properly) - rust-lang#133133 (rustdoc-search: add standalone trailing `::` test) - rust-lang#133143 (Diagnostics for let mut in item context) - rust-lang#133147 (Fixup some test directives) r? `@ghost` `@rustbot` modify labels: rollup
No functional change (yet).
…BoxyUwU Fix closure arg extraction in `extract_callable_info`, generalize it to async closures * Fix argument extraction in `extract_callable_info` * FIx `extract_callable_info` to work for async closures * Remove redundant `is_fn_ty` which is just a less general `extract_callable_info` * More precisely name what is being called (i.e. call it a "closure" not a "function") Review this without whitespace -- I ended up reformatting `extract_callable_info` because some pesky `//` comments were keeping the let-chains from being formatted.
tests: ui/inline-consts: add issue number to a test, rename other tests rename other tests from a_b_c to a-b-c
Don't exclude relnotes from `needs-triage` label So initially we *didn't* exclude `needs-triage` label, then we did exclude them in rust-lang#132825 as sometimes the `needs-triage` is redundant. However, I think they are probably worth double-checking because often some of the labels are only accurate/relevant for the *implementation* PR, but not for the purposes of the relnotes tracking issue. Furthermore, sometimes relevant team labels can be removed. So to make it less likely for relnotes to slip through, I think we should still label relnotes-tracking-issues with `needs-triage`. cc https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Please.20CC.20lang r? release
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#130236 (unstable feature usage metrics) - rust-lang#131544 (Make asm label blocks safe context) - rust-lang#131586 (Support s390x z13 vector ABI) - rust-lang#132489 (Fix closure arg extraction in `extract_callable_info`, generalize it to async closures) - rust-lang#133078 (tests: ui/inline-consts: add issue number to a test, rename other tests) - rust-lang#133283 (Don't exclude relnotes from `needs-triage` label) r? `@ghost` `@rustbot` modify labels: rollup
fmt fix cfg for windows remove unused imports address comments update libc to 0.2.164 fmt remove unused imports
…le, r=Kobzol ci: Disable full `debuginfo-level=2` in windows alt job try-job: dist-x86_64-msvc-alt
…ouxu [AIX] change system dynamic library format Historically on AIX, almost all dynamic libraries are distributed in `.a` Big Archive Format which can consists of both static and shared objects in the same archive (e.g. `libc++abi.a(libc++abi.so.1)`). During the initial porting process, the dynamic libraries are kept as `.a` to simplify the migration, but semantically having an XCOFF object under the archive extension is wrong. For crate type `cdylib` we want to be able to distribute the libraries as archives as well. We are migrating to archives with the following format: ``` $ ar -t lib<name>.a lib<name>.so ``` where each archive contains a single member that is a shared XCOFF object that can be loaded.
Is available since libc 0.2.162
…al, r=dtolnay
Stabilize `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local`
Make `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local` stable (+const).
Newly stable API:
```rust
impl Ipv6Addr {
// Newly stable under `ipv6_is_unique_local`
const fn is_unique_local(&self) -> bool;
// Newly stable under `ipv6_is_unique_local`
const fn is_unicast_link_local(&self) -> bool;
}
```
These stabilise a subset of the following tracking issue:
- rust-lang#27709
I have looked and could not find any issues with `is_unique_local` and `is_unicast_link_local`. There is a well received comment calling for stabilisation of the latter function.
Both functions are well defined and consistent with implementations in other languages:
- [Go](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/net/netip/netip.go;l=518)
- [Python](https://github.com/python/cpython/blob/e9d1bf353c3ccafc0d9b61b1b3688051bc976604/Lib/ipaddress.py#L2319-L2321)
- [Ruby (unique local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#private-3F-source)
- [Ruby (unicast link local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#link_local-3F-source)
cc implementor `@little-dude`
(I can't find the original PR for `is_unqiue_local`)
r? libs-api
`@rustbot` label +T-libs-api +needs-fcp
distinguish overflow and unimplemented in Step::steps_between
…anieu re-export `is_loongarch_feature_detected` r? ``@Amanieu``
…=jhpratt Support `each_ref` and `each_mut` in `[T; N]` in constant expressions. Tracking issue: rust-lang#133289 The methods `<[T; N]>::each_ref` and `<[T; N]>::each_mut` can easily be reimplemented to allow marking them with the `const` specifier. This specific implementation takes a different approach than the original as to avoid using iterators (which are illegal in constant expressions).
Miri subtree update r? `@ghost`
Use arc4random of libc for RTEMS target Switch to the `arc4random` from libc. It is available since libc 0.2.162
…=lcnr Simplify `fulfill_implication` calm before the storm
…r=lcnr Bail in effects in old solver if self ty is ty var Otherwise when we try to check something like `?t: ~const Trait` we'll immediately stick it to the first param-env candidate, lol. r? lcnr
library: update comment around close() r? `@the8472`
… r=joboet Fix typo in `std::thread::Scope::spawn` documentation. Just a simple fix for a typo that caught my attention.
Rollup of 8 pull requests Successful merges: - rust-lang#133238 (re-export `is_loongarch_feature_detected`) - rust-lang#133288 (Support `each_ref` and `each_mut` in `[T; N]` in constant expressions.) - rust-lang#133311 (Miri subtree update) - rust-lang#133313 (Use arc4random of libc for RTEMS target) - rust-lang#133319 (Simplify `fulfill_implication`) - rust-lang#133323 (Bail in effects in old solver if self ty is ty var) - rust-lang#133330 (library: update comment around close()) - rust-lang#133337 (Fix typo in `std::thread::Scope::spawn` documentation.) r? `@ghost` `@rustbot` modify labels: rollup
yaahc
force-pushed
the
z-unstable-feature-status
branch
from
a50a3e1 to
7a06cbf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.