rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2019-10-25	Rollup merge of #65790 - Centril:move-report-invalid, r=davidtwco	Mazdak Farrokhzad	-0/+20
	move report_invalid_macro_expansion_item to item.rs From https://github.com/rust-lang/rust/pull/65324. r? @Mark-Simulacrum
2019-10-25	move report_invalid_macro_expansion_item to item.rs	Mazdak Farrokhzad	-0/+20

2019-10-24	pre-expansion gate type_ascription	Mazdak Farrokhzad	-0/+1

2019-10-24	pre-expansion gate box_syntax	Mazdak Farrokhzad	-1/+3

2019-10-24	pre-expansion gate label_break_value	Mazdak Farrokhzad	-0/+4

2019-10-24	pre-expansion gate try_blocks	Mazdak Farrokhzad	-1/+3

2019-10-24	pre-expansion gate exclusive_range_pattern	Mazdak Farrokhzad	-2/+7

2019-10-24	pre-expansion gate box_patterns	Mazdak Farrokhzad	-1/+3

2019-10-24	pre-expansion gate decl_macro	Mazdak Farrokhzad	-0/+5

2019-10-24	pre-expansion gate const_generics	Mazdak Farrokhzad	-0/+4

2019-10-24	pre-expansion gate associated_type_bounds	Mazdak Farrokhzad	-2/+10

2019-10-24	pre-expansion gate trait_alias.	Mazdak Farrokhzad	-0/+2

2019-10-24	syntax: reject `trait Foo: Bar = Baz;`.	Mazdak Farrokhzad	-8/+20
	Add test for rejecting `trait A: B1 = B2;`. Also test rejection of `trait A: = B;`.
2019-10-23	Rollup merge of #65686 - yjhmelody:yjhmelody-patch-1, r=Centril	Yuki Okushi	-2/+8
	refactor and move `maybe_append`
2019-10-22	refactor maybe_append	yjhmelody	-2/+8

2019-10-18	Rollup merge of #65552 - JohnTitor:use-bitwise-not, r=Dylan-DPC	Tyler Mandry	-1/+1
	Clarify diagnostics when using `~` as a unary op It seems we prefer `bitwise not` to `bitwise negation`. Fixes #57239 r? @estebank
2019-10-18	Clarify diagnostics when using `~` as a unary op	Yuki Okushi	-1/+1

2019-10-18	Change `Lit::tokens()` to `Lit::token_tree()`.	Nicholas Nethercote	-5/+4
	Because most of the call sites have an easier time working with a `TokenTree` instead of a `TokenStream`.
2019-10-16	ui-fulldeps: make them pass again?	Mazdak Farrokhzad	-2/+2

2019-10-16	make tidy happy	Mazdak Farrokhzad	-3/+13

2019-10-16	parser: leave a FIXME for later	Mazdak Farrokhzad	-0/+2

2019-10-16	move SeqSep to parser.rs	Mazdak Farrokhzad	-4/+5

2019-10-16	move syntax::ext to new crate syntax_expand	Mazdak Farrokhzad	-15/+15

2019-10-16	syntax::parse: don't depend on syntax::ext	Mazdak Farrokhzad	-6/+12

2019-10-16	syntax: reduce visibilities	Mazdak Farrokhzad	-65/+67

2019-10-16	move diagnostics.rs into parser/	Mazdak Farrokhzad	-4/+1488

2019-10-16	syntax: extract parse_cfg_attr	Mazdak Farrokhzad	-0/+21

2019-10-16	syntax: extract parse_derive_paths	Mazdak Farrokhzad	-1/+16

2019-10-16	move parse::attr -> parse::parser::attr	Mazdak Farrokhzad	-0/+330

2019-10-15	move parse_lit to expr.rs	Mazdak Farrokhzad	-6/+166

2019-10-14	Rollup merge of #65410 - Centril:intersection-pat-recover, r=davidtwco,varkor	Tyler Mandry	-0/+60
	syntax: add parser recovery for intersection- / and-patterns `p1 @ p2` Fixes https://github.com/rust-lang/rust/issues/65400. The recovery comes in two flavors: 1. We know that `p2` is a binding so we can invert as `p2 @ p1`: ```rust error: pattern on wrong side of `@` --> $DIR/intersection-patterns.rs:13:9 \| LL \| Some(x) @ y => {} \| -------^^^- \| \| \| \| \| binding on the right, should be to the left \| pattern on the left, should be to the right \| help: switch the order: `y @ Some(x)` ``` 2. Otherwise we emit a generic diagnostic for the lack of support for intersection patterns: ```rust error: left-hand side of `@` must be a binding --> $DIR/intersection-patterns.rs:23:9 \| LL \| Some(x) @ Some(y) => {} \| -------^^^------- \| \| \| \| \| also a pattern \| interpreted as a pattern, not a binding \| = note: bindings are `x`, `mut x`, `ref x`, and `ref mut x` ``` For more on and-patterns, see e.g. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching#and-pattern. r? @davidtwco cc @varkor @lzutao
2019-10-14	recover_intersection_pat: adjust wording	Mazdak Farrokhzad	-3/+3

2019-10-14	syntax: use `PatKind::Wild` as our `::Err` equivalent.	Mazdak Farrokhzad	-10/+10

2019-10-14	syntax: add recovery for intersection patterns `p1 @ p2`	Mazdak Farrokhzad	-0/+60

2019-10-14	Rollup merge of #65363 - Centril:less-pprust, r=Mark-Simulacrum	Mazdak Farrokhzad	-2/+5
	Remove implicit dependencies on syntax::pprust Part of https://github.com/rust-lang/rust/pull/65324. The main goal here is to facilitate the eventual move of pprust out from libsyntax and because an AST definition typically should not depend on its pretty printer. r? @estebank
2019-10-13	syntax: consolidate function parsing in `item.rs`	Mazdak Farrokhzad	-206/+487

2019-10-13	ast: remove implicit pprust dependency via Display.	Mazdak Farrokhzad	-2/+5
	Instead just use `pprust::path_to_string(..)` where needed. This has two benefits: a) The AST definition is now independent of printing it. (Therefore we get closer to extracting a data-crate.) b) Debugging should be easier as program flow is clearer.
2019-10-07	syntax: refactor with new `fn parse_use_tree_glob_or_nested`.	Mazdak Farrokhzad	-10/+11

2019-10-07	syntax: use `parse_extern_abi` more.	Mazdak Farrokhzad	-8/+1

2019-10-07	syntax: unify and simplify fn signature parsing.	Mazdak Farrokhzad	-33/+36

2019-10-07	syntax: unify trait parsing a bit.	Mazdak Farrokhzad	-17/+12

2019-10-07	syntax: further item parsing cleanup	Mazdak Farrokhzad	-24/+35

2019-10-07	syntax: de-dups in item parsing.	Mazdak Farrokhzad	-50/+44

2019-10-07	syntax: cleanup associated const parsing.	Mazdak Farrokhzad	-32/+39

2019-10-07	Auto merge of #64906 - Aaron1011:feature/extern-const-fn, r=Centril	bors	-19/+34
	Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: https://github.com/rust-lang/rust/issues/64926.
2019-10-05	Rollup merge of #65123 - Centril:mac-invoc-in-mut-pat, r=estebank	Tyler Mandry	-1/+5
	Account for macro invocation in `let mut $pat` diagnostic. Fixes https://github.com/rust-lang/rust/issues/65122. r? @estebank
2019-10-05	Account for macro invocation in `let mut $pat` diagnostic.	Mazdak Farrokhzad	-1/+5

2019-10-03	When encountering chained operators use heuristics to recover from bad turbofish	Esteban Küber	-1/+3

2019-10-02	Add missing 'bump'	Aaron Hill	-0/+1

2019-10-02	Add support for 'extern const fn'	Aaron Hill	-19/+33
	This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.