https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.50.0 2020-12-25T02:39:35+00:00 2020-12-25T02:39:35+00:00 Dylan DPC dylan.dpc@gmail.com 2020-12-25T02:39:35+00:00 urn:sha1:299c2fc69554998e8991715d09a611376a5b9cf3 Implemented a compiler diagnostic for move async mistake Fixes #79694 First time contributing, so I hope I'm doing everything right. (If not, please correct me!) This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it. Checked code: ```rust fn main() { move async { }; } ``` Previous output: ```txt PS C:\Repos\move_async_test> cargo build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: expected one of `|` or `||`, found keyword `async` --> src\main.rs:2:10 | 2 | move async { }; | ^^^^^ expected one of `|` or `||` error: aborting due to previous error error: could not compile `move_async_test` ``` New output: ```txt PS C:\Repos\move_async_test> cargo +dev build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: the order of `move` and `async` is incorrect --> src\main.rs:2:13 | 2 | let _ = move async { }; | ^^^^^^^^^^ | help: try switching the order | 2 | let _ = async move { }; | ^^^^^^^^^^ error: aborting due to previous error error: could not compile `move_async_test` ``` Is there a file/module where these kind of things are tested? Would love some feedback 😄 2020-12-21T11:57:08+00:00 Dion Dokter diondokter@gmail.com 2020-12-18T16:32:26+00:00 urn:sha1:a272d621bc7a2ca61d704fbe531dc532d49ab402 Ran the tidy check Following the diagnostic guide better Diagnostic generation is now relegated to its own function in the diagnostics module. Added tests Fixed the ui test 2020-12-19T13:13:36+00:00 mark markm@cs.wisc.edu 2020-11-11T00:00:53+00:00 urn:sha1:1a7d00a529503ac38a6b1ae28e8e779e434e02e0 2020-12-19T01:47:05+00:00 bors bors@rust-lang.org 2020-12-19T01:47:05+00:00 urn:sha1:d1741e59cb87d3c8c794eebf6d5430d1b383f51f Gracefully handle mistyping -> as => in function return type Fixes #77019 2020-12-17T21:58:56+00:00 Camelid camelidcamel@gmail.com 2020-12-17T21:51:20+00:00 urn:sha1:d6f1787447e1132d929efbb5b772be232e336c23 Thanks to Vadim Petrochenkov who [told me what the fix was][z]! [z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/finding.20which.20macro.20rule.20to.20use/near/220240422 2020-12-17T13:12:48+00:00 mibac138 5672750+mibac138@users.noreply.github.com 2020-12-17T12:44:08+00:00 urn:sha1:e916641fd35bddabc8b018a5e51fe23b93875c66 2020-12-13T19:31:06+00:00 bors bors@rust-lang.org 2020-12-13T19:31:06+00:00 urn:sha1:803c60218ffac3384b0063c1b87ae7944163bba7 Properly capture trailing 'unglued' token If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll need to capture a `>` token which was 'unglued' from a `>>` token. The processing of unglueing a token for parsing purposes bypasses the usual capturing infrastructure, so we currently lose the trailing `>`. As a result, we fall back to the reparsed `TokenStream`, causing us to lose spans. This commit makes token capturing keep track of a trailing 'unglued' token. Note that we don't need to care about unglueing except at the end of the captured tokens - if we capture both the first and second unglued tokens, then we'll end up capturing the full 'glued' token, which already works correctly. 2020-12-13T10:52:29+00:00 bors bors@rust-lang.org 2020-12-13T10:52:29+00:00 urn:sha1:057937bddac3f43a46dfc07ee2d9fa59de7b7ca9 Recover on `const impl<> X for Y` `@leonardo-m` mentioned that `const impl Foo for Bar` could be recovered from in #79287. I'm not sure about the error strings as they are, I think it should probably be something like the error that `expected_one_of_not_found` makes + the suggestion to flip the keywords, but I'm not sure how exactly to do that. Also, I decided not to try to handle `const unsafe impl` or `unsafe const impl` cause I figured that `unsafe impl const` would be pretty rare anyway (if it's even valid?), and it wouldn't be worth making the code more messy. 2020-12-12T21:28:13+00:00 Aaron Hill aa1ronham@gmail.com 2020-12-12T20:20:22+00:00 urn:sha1:e6fa6334dd54f7c96514b520c5b9f261df3fc16b If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll need to capture a `>` token which was 'unglued' from a `>>` token. The processing of unglueing a token for parsing purposes bypasses the usual capturing infrastructure, so we currently lose the trailing `>`. As a result, we fall back to the reparsed `TokenStream`, causing us to lose spans. This commit makes token capturing keep track of a trailing 'unglued' token. Note that we don't need to care about unglueing except at the end of the captured tokens - if we capture both the first and second unglued tokens, then we'll end up capturing the full 'glued' token, which already works correctly. 2020-12-12T20:45:54+00:00 Noah 33094578+coolreader18@users.noreply.github.com 2020-12-03T18:37:19+00:00 urn:sha1:1e27b65d8e877fd33ff8de20c359282577b8956c