-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 14 pull requests #81754
Closed
Closed
Rollup of 14 pull requests #81754
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
Change filesearch::get_or_default_sysroot() to check if sysroot is found using env::args().next() if rustc in argv[0] is a symlink; otherwise, or if it is not found, use env::current_exe() to imply sysroot. This makes the rustc binary able to locate Rust libraries in systems using content-addressable storage (CAS).
This makes it clear that it's an implementation detail of `display_fn` and shouldn't be used elsewhere, and it enforces in the compiler that no one else can use it.
We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.
Per a comment on rust-lang#70516 this changes `eq_ignore_ascii_case` to take the generic parameter `S: AsRef<OsStr>` by value instead of by reference. This is technically a breaking change to an unstable method. I think the only way it would break is if you called this method with an explicit type parameter, ie `my_os_str.eq_ignore_ascii_case::<str>("foo")` becomes `my_os_str.eq_ignore_ascii_case::<&str>("foo")`. Besides that, I believe it is overall more flexible since it can now take an owned `OsString` for example. If this change should be made in some other PR (like rust-lang#80193) then please just close this.
Co-Authored-By: Ashley Mannix <[email protected]>
This comes up a lot when bootstrapping.
This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021. It suggests to add `"{}", ` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized `std::panic::panic_any()` function as an alternative. It renames the lint to `non_fmt_panic` to match the lint naming guidelines.
This stabilizes: * `OnceState` * `OnceState::is_poisoned()` (previously named `poisoned()`) * `Once::call_once_force()` `poisoned()` was renamed because the new name is more clear as a few people agreed and nobody objected. Closes rust-lang#33577
Stabilize the Wake trait This PR proposes stabilizing the `wake_trait` feature, tracking issue rust-lang#69912. ## Motivation The surface area this trait introduces is small, and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this. Personally I would love to have this available on stable, since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended. ## Implementation notes This PR itself fixes a link in the docs, and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting, but is intended to serve as a teaching device for both `task::Wake` and futures alike.
…gisa Fix rustc sysroot in systems using CAS Change filesearch::get_or_default_sysroot() to check if sysroot is found using env::args().next() if rustc in argv[0] is a symlink; otherwise, or if it is not found, use env::current_exe() to imply sysroot. This makes the rustc binary able to locate Rust libraries in systems using content-addressable storage (CAS).
Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question, but the discussion on [the tracking issue](rust-lang#68125) seems to have converged to `reduce`.
rustdoc-json: Fix has_body Previously, `has_body` was always true. Now propagate the type of the method to set it correctly. Relies on rust-lang#81287, that will need to be merged first.
…ell, r=jyn514 rustdoc: Move `display_fn` struct inside `display_fn` This makes it clear that it's an implementation detail of `display_fn` and shouldn't be used elsewhere, and it enforces in the compiler that no one else can use it. r? ``@GuillaumeGomez``
…lint, r=pnkfelix introduce future-compatibility warning for forbidden lint groups We used to ignore `forbid(group)` scenarios completely. This changed in rust-lang#78864, but that led to a number of regressions (rust-lang#80988, rust-lang#81218). This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect. r? `@Mark-Simulacrum`
…1995 Add lint for `panic!(123)` which is not accepted in Rust 2021. This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021. It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized `std::panic::panic_any()` function as an alternative. It renames the lint to `non_fmt_panic` to match the lint naming guidelines. ![image](https://user-images.githubusercontent.com/783247/106520928-675ea680-64d5-11eb-81f7-d8fa48b93a0b.png) This is part of rust-lang#80162. r? ``@estebank``
Add more information to the error code for 'crate not found' This comes up a lot when bootstrapping.
…, r=oli-obk Add additional bitset benchmarks Add additional benchmarks for operations in bitset, I realize that it was a bit lacking when I intended to optimize it earlier, so I was hoping to put some in so I can verify my work later.
OsStr eq_ignore_ascii_case takes arg by value Per a comment on rust-lang#70516 this changes `eq_ignore_ascii_case` to take the generic parameter `S: AsRef<OsStr>` by value instead of by reference. This is technically a breaking change to an unstable method. I think the only way it would break is if you called this method with an explicit type parameter, ie `my_os_str.eq_ignore_ascii_case::<str>("foo")` becomes `my_os_str.eq_ignore_ascii_case::<&str>("foo")`. Besides that, I believe it is overall more flexible since it can now take an owned `OsString` for example. If this change should be made in some other PR (like rust-lang#80193) then please just close this.
add #[inline] to all the public IpAddr functions
Move test to be with the others No functional changes. I just created this test in the wrong place in a past PR. All of the other or-pattern tests are in the `or-patterns` directory.
…mulacrum Revert stabilizing integer::BITS. We agreed in the libs meeting just now to revert stablization, since the [breakage](rust-lang#81654) is significant throughout the ecosystem, through `lexical-core`. cc rust-lang#76904 Fixes rust-lang#81654
…ou-se Stabilize poison API of Once, rename poisoned() This stabilizes: * `OnceState` * `OnceState::is_poisoned()` (previously named `poisoned()`) * `Once::call_once_force()` `poisoned()` was renamed because the new name is more clear as a few people agreed and nobody objected. Closes rust-lang#33577 Notes: * I'm not entirely sure it's supposed to be 1.51, LMK if I did it wrong * I failed to run tests locally, so we will have to leave it to bors or someone else can try
@bors r+ p=14 rollup=never |
📌 Commit 7066afb has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Feb 4, 2021
⌛ Testing commit 7066afb with merge d35224778576c945781909dd06d14b3673fe45bc... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Feb 4, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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.
Successful merges:
display_fn
struct insidedisplay_fn
#81497 (rustdoc: Movedisplay_fn
struct insidedisplay_fn
)panic!(123)
which is not accepted in Rust 2021. #81645 (Add lint forpanic!(123)
which is not accepted in Rust 2021.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup