-
Notifications
You must be signed in to change notification settings - Fork 13k
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 8 pull requests #66417
Rollup of 8 pull requests #66417
Conversation
Rename * Error::iter_chain() -> Error::chain() * ErrorIter -> Chain Removed * Error::iter_sources() according to rust-lang#58520 Rationale: 1. Such iterators are helpful. They should better be stabilized sooner than later. 2. self should be included. It is easy to .skip(1) it. Not including self is harmful because it is harder to add self to the iterator than to remove it. 3. The chosen name should be telling and reflect the fact that self is included. `.chain()` was chosen because the iterator iterates over the chain of errors that is somehow included in self. 4. The resulting iterator is named `Chain` because the `error::Chain` is what we want to have.
The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based, and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: <std::future::GenFuture<T> as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely, we can improve things a bit in the meantime. In particular, this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context`, removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure, removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard, but that requires adjusting the code generated for .await, so I've left that off for now.
rename Error::iter_chain() and remove Error::iter_sources() ~~Rename~~ * ~~Error::iter_chain() -> Error::chained()~~ * ~~Error::iter_sources() -> Error::ancestors()~~ * ~~ErrorIter -> Chained and Ancestors~~ according to rust-lang#58520 (comment) Tracker: rust-lang#58520 Edit: Rename * Error::iter_chain() -> Error::chained() * ErrorIter -> Chain So, it seems, that even Path::ancestors() includes itself. So, to avoid confusion and simplify it more, I reduced PR rust-lang#65557 to only have `chained` and `Chain`. Rationale: 1. Such iterators are helpful. They should better be stabilized sooner than later. 1. self should be included. It is easy to .skip(1) it. Not including self is harmful because it is harder to add self to the iterator than to remove it. 1. The chosen name should be telling and reflect the fact that self is included. `.chained()` was chosen in honor of error-chain and because the iterator iterates over the chain of errors that is somehow included in self. 1. The resulting iterator is named `Chain` because the `error::Chain` is what we want to have.
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported. r? @varkor
…miri, r=oli-obk Remove cannot mutate statics in initializer of another static error r? @oli-obk This is just a refactoring. As the removed code itself said, it only a heuristic catching a few cases early instead of leaving it all to const eval. It's easy to work around the static check and then run into the miri-engine check.
Update mdbook. This brings in some important updates to fix some rendering issues in the books. In particular fixing hidden lines in code blocks, and some escaping issues. More details at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md This also requires updating mdbook-linkcheck.
Fix two OOM issues related to `ConstProp` Fixes rust-lang#66342 Fixes rust-lang#66397 r? @oli-obk
Make a test compatible across python versions. Progress on rust-lang#65063 This PR allows this test to work on both python2 and python3, and it also allows `./x.py test` to fully complete on my system without python2 installed at all.
Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based, and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: <std::future::GenFuture<T> as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely, we can improve things a bit in the meantime. In particular, this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context`, removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure, removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard, but that requires adjusting the code generated for .await, so I've left that off for now.
miri: helper methods for max values of machine's usize/isize We recently wanted this in Miri. r? @oli-obk
@bors r+ p=8 rollup=never |
📌 Commit e3bbc0d has been approved by |
⌛ Testing commit e3bbc0d with merge d82770e98a6d964787e562157d173ced73d22b5b... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
@bors r- Broken by #66417 (comment) |
Successful merges:
ast::{ItemKind, ImplItemKind}::OpaqueTy
hack down into lowering #66197 (Pushast::{ItemKind, ImplItemKind}::OpaqueTy
hack down into lowering)ConstProp
#66394 (Fix two OOM issues related toConstProp
).async
calls #66398 (Remove some stack frames from.async
calls)Failed merges:
r? @ghost