-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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 7 pull requests #61630
Rollup of 7 pull requests #61630
Conversation
The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading, the "correct" name would be `replace_with_default`, which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take`, so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested, but was deemed too verbose, especially given that we use `take` for methods that replace with `Default` elsewhere.
Add std::mem::take as suggested in rust-lang#61129 This PR implements rust-lang#61129 by adding `std::mem::take`. The added function is equivalent to: ```rust std::mem::replace(dest, Default::default()) ``` This particular pattern is fairly common, especially when implementing `Future::poll`, where you often need to yield an owned value in `Async::Ready`. This change allows you to write ```rust return Async::Ready(std::mem::take(self.result)); ``` instead of ```rust return Async::Ready(std::mem::replace(self.result, Vec::new())); ``` EDIT: Changed name from `take` to `swap_default`. EDIT: Changed name back to `take`.
Bump dirs, rand and redox_users Part of rust-lang#57724.
syntax: Treat error literals in more principled way Free them from their character literal origins. I actually tried to remove `LitKind::Err` entirely (by converting it into `ExprKind::Err` immediately), and it caused no diagnostic regressions in the test suite. However, I'd still want to use error literals as general purpose error tokens some day, so I kept them. The downside of having `LitKind::Err` in addition to `ExprKind::Err` is that every time you want to do something with `ExprKind::Err` you need to make sure that `ExprKind::Lit(LitKind::Err)` is treated in the same way. Fortunately, this usually happens automatically because both literals and errors are "leaf" expressions, however this PR does fix a couple of inconsistencies between them. Addresses rust-lang#60679 (comment) in a way
parser: Remove `Deref` impl from `Parser` Follow up to rust-lang#61541 You have to write `self.token.span` instead of `self.span` in the parser now, which is not nice, but not too bad either, I guess. Not sure. Probably still better than people using both and being confused about the definition point of `span`. r? @oli-obk @estebank
…hosts, r=alexcrichton Clarify when we run steps with ONLY_HOSTS Just some simple cleanup, no behavior changes. r? @alexcrichton
Rename remaining "Eval" to "Interp" Renaming done by sed. r? @oli-obk Fixes rust-lang#54395.
…crichton Add regression test for rust-lang#61452. Fixes rust-lang#61452. Turns out this ICE had already been fixed, so this PR only adds a regression test.
@bors r+ rollup=never p=7 |
📌 Commit 08b6bce has been approved by |
⌛ Testing commit 08b6bce with merge c842be2a37eb418eda3e762da21482816c99aba3... |
💔 Test failed - checks-travis |
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 |
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 |
Successful merges:
Deref
impl fromParser
#61616 (parser: RemoveDeref
impl fromParser
)Failed merges:
r? @ghost