https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.22.0 2017-10-06T10:17:40+00:00 2017-10-06T10:17:40+00:00 Seiichi Uchida seuchida@gmail.com 2017-10-06T10:16:16+00:00 urn:sha1:14c6c119042d2cfbaea0e17e47d2c160261e73ab 2017-10-03T09:47:33+00:00 Philip Craig philipjcraig@gmail.com 2017-10-03T09:44:58+00:00 urn:sha1:3a225c77bba8576333924e7435493cb4d4e0cbaf 2017-09-30T06:32:45+00:00 Philip Craig philipjcraig@gmail.com 2017-09-30T06:28:48+00:00 urn:sha1:c27a82f19352f37a6b04d7733d28c84494c3afd4 2017-09-27T16:04:31+00:00 bors bors@rust-lang.org 2017-09-27T16:04:31+00:00 urn:sha1:0e6f4cf51cd3b799fb057956f8e733d16605d09b Initial support for `..=` syntax #28237 This PR adds `..=` as a synonym for `...` in patterns and expressions. Since `...` in expressions was never stable, we now issue a warning. cc @durka r? @aturon 2017-09-22T20:05:18+00:00 Badel2 2badel2@gmail.com 2017-09-21T10:13:26+00:00 urn:sha1:7aabf572789dcae24cc8ce247f7d86bcc5d49a17 ... or ..= 2017-09-22T20:05:18+00:00 Alex Burka alex@alexburka.com 2017-09-19T05:40:04+00:00 urn:sha1:e64efc91f49affb265328e354c8c8f0544daa462 Add ..= to the parser Add ..= to libproc_macro Add ..= to ICH Highlight ..= in rustdoc Update impl Debug for RangeInclusive to ..= Replace `...` to `..=` in range docs Make the dotdoteq warning point to the ... Add warning for ... in expressions Updated more tests to the ..= syntax Updated even more tests to the ..= syntax Updated the inclusive_range entry in unstable book 2017-09-21T16:19:34+00:00 Seiichi Uchida seuchida@gmail.com 2017-09-21T16:19:34+00:00 urn:sha1:ded73a85e2dd258e81db19d9320f87e5389ae87a 2017-09-19T00:20:12+00:00 Alex Crichton alex@alexcrichton.com 2017-09-15T15:28:34+00:00 urn:sha1:0694e4fde4c4abd13dffa82a571c7a9559b19fb1 Right now the HIR contains raw `syntax::ast::Attribute` structure but nowadays these can contain arbitrary tokens. One variant of the `Token` enum is an "interpolated" token which basically means to shove all the tokens for a nonterminal in this position. A "nonterminal" in this case is roughly analagous to a macro argument: macro_rules! foo { ($a:expr) => { // $a is a nonterminal as an expression } } Currently nonterminals contain namely items and expressions, and this poses a problem for incremental compilation! With incremental we want a stable hash of all HIR items, but this means we may transitively need a stable hash *of the entire AST*, which is certainly not stable w/ node ids and whatnot. Hence today there's a "bug" where the "stable hash" of an AST is just the raw hash value of the AST, and this only arises with interpolated nonterminals. The downside of this approach, however, is that a bunch of errors get spewed out during compilation about how this isn't a great idea. This PR is focused at fixing these warnings, basically deleting them from the compiler. The implementation here is to alter attributes as they're lowered from the AST to HIR, expanding all nonterminals in-place as we see them. This code for expanding a nonterminal to a token stream already exists for the `proc_macro` crate, so we basically just reuse the same implementation there. After this PR it's considered a bug to have an `Interpolated` token and hence the stable hash implementation simply uses `bug!` in this location. Closes #40946 2017-09-17T18:19:24+00:00 Tamir Duberstein tamird@gmail.com 2017-09-08T19:08:01+00:00 urn:sha1:231d9e7e5d87ed54015c22bb1a07d0f3d4c0befa 2017-09-14T00:28:27+00:00 bors bors@rust-lang.org 2017-09-14T00:28:27+00:00 urn:sha1:d1ca653b170c235ad01a83d89fcb18b1f8b6a3b0 Parse nested closure with two consecutive parameter lists properly This is a followup of #44332. --- Currently, in nightly, this does not compile: ```rust fn main() { let f = |_||x, y| x+y; println!("{}", f(())(1, 2)); // should print 3 } ``` `|_||x, y| x+y` should be parsed as `|_| (|x, y| x+y)`, but the parser didn't accept `||` between `_` and `x`. This patch fixes the problem. r? @petrochenkov