| Age | Commit message (Collapse) | Author | Lines |
|---|
|
+ Rebase fixes
|
|
Part of https://github.com/rust-lang/rust/pull/30095 not causing mysterious segfaults.
r? @nrc
|
|
Should make it possible to add JSON or HTML errors. Also tidies up a lot.
|
|
|
|
|
|
Also split out emitters into their own module.
|
|
+ Apply parser changes manually
+ Add feature gate
|
|
|
|
Changed bit manipulation to use supported - (set difference) instead
of explicit '& !'.
|
|
|
|
RESTRICTION_STMT_EXPR restriction to allow subsequent expressions to
contain braces.
https://github.com/rust-lang/rust/issues/28777
|
|
See https://github.com/rust-lang/rfcs/pull/16 and https://github.com/rust-lang/rust/issues/15701
- Added syntax support for attributes on expressions and all syntax nodes in statement position.
- Extended `#[cfg]` folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.
- Extended lint checker to recognize lint levels on expressions and
locals.
- As per RFC, attributes are not yet accepted on `if` expressions.
Examples:
```rust
let x = y;
{
...
}
assert_eq!((1, #[cfg(unset)] 2, 3), (1, 3));
let FOO = 0;
```
Implementation wise, there are a few rough corners and open questions:
- The parser work ended up a bit ugly.
- The pretty printer change was based mostly on guessing.
- Similar to the `if` case, there are some places in the grammar where a new `Expr` node starts,
but where it seemed weird to accept attributes and hence the parser doesn't. This includes:
- const expressions in patterns
- in the middle of an postfix operator chain (that is, after `.`, before indexing, before calls)
- on range expressions, since `#[attr] x .. y` parses as `(#[attr] x) .. y`, which is inconsistent with
`#[attr] .. y` which would parse as `#[attr] (.. y)`
- Attributes are added as additional `Option<Box<Vec<Attribute>>>` fields in expressions and locals.
- Memory impact has not been measured yet.
- A cfg-away trailing expression in a block does not currently promote the previous `StmtExpr` in a block to a new trailing expr. That is to say, this won't work:
```rust
let x = {
#[cfg(foo)]
Foo { data: x }
#[cfg(not(foo))]
Foo { data: y }
};
```
- One-element tuples can have their inner expression removed to become Unit, but just Parenthesis can't. Eg, `(#[cfg(unset)] x,) == ()` but `(#[cfg(unset)] x) == error`. This seemed reasonable to me since tuples and unit are type constructors, but could probably be argued either way.
- Attributes on macro nodes are currently unconditionally dropped during macro expansion, which seemed fine since macro disappear at that point?
- Attributes on `ast::ExprParens` will be prepend-ed to the inner expression in the hir folder.
- The work on pretty printer tests for this did trigger, but not fix errors regarding macros:
- expression `foo![]` prints as `foo!()`
- expression `foo!{}` prints as `foo!()`
- statement `foo![];` prints as `foo!();`
- statement `foo!{};` prints as `foo!();`
- statement `foo!{}` triggers a `None` unwrap ICE.
|
|
|
|
|
|
nodes in statement position.
Extended #[cfg] folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.
Extended lint checker to recognize lint levels on expressions and
locals.
|
|
|
|
|
|
Since these functions are only used by the AST quoting syntax extensions, they should be there instead of in the parser.
|
|
Just `sed s/_nopanic//g`. Hopefully makes libsyntax a bit more
readable.
|
|
cc @nagisa
|
|
|
|
This is my first code contribution to Rust, so I'm sure there are some issues with the changes I've made.
I've added the `quote_arg!`, `quote_block!`, `quote_path!`, and `quote_meta_item!` quasiquoting macros. From my experience trying to build AST in compiler plugins, I would like to be able to build any AST piece with a quasiquoting macro (e.g., `quote_struct_field!` or `quote_variant!`) and then use those AST pieces in other quasiquoting macros, but this pull request just adds some of the low-hanging fruit.
I'm not sure if these additions are desirable, and I'm sure these macros can be implemented in an external crate if not.
|
|
|
|
|
|
Just `sed s/_nopanic//g`. Hopefully makes libsyntax a bit more
readable.
|
|
|
|
|
|
|
|
[breaking change]
|
|
&format!("...") is the same as "" if we're not doing any interpolation,
and doesn't allocate an intermediate String.
|
|
A set of commits which pushes some panics out of core parser methods, and into users of those parser methods.
|
|
|
|
keyword
|
|
Rename parse_* to parse_*_panic, and add parse_attribute_panic.
|
|
|
|
|
|
|
|
Also add some (regression) tests for discovered parser oddities
|
|
|
|
|
|
This commit generalises parsing of associative operators from left-associative
only (with some ugly hacks to support right-associative assignment) to properly
left/right-associative operators.
Parsing still is not general enough to handle non-associative,
non-highest-precedence prefix or non-highest-precedence postfix operators (e.g.
`..` range syntax), though. That should be fixed in the future.
Lastly, this commit adds support for parsing right-associative `<-` (left arrow)
operator with precedence higher than assignment as the operator for placement-in
feature.
|
|
r=nikomatsakis
This PR switches the implemented ordering from `unsafe const fn` (as was in the original RFC) to `const unsafe fn` (which is what the lang team decided on)
|
|
Previously, if you copied a signature from a trait definition such as:
```rust
fn foo<'a>(&'a Bar) -> bool {}
```
and moved it into an `impl`, there would be an error message:
"unexpected token `'a`"
Adding to the error message that a pattern is expected should help
users to find the actual problem with using a lifetime here.
|
|
And use `VariantData` instead of `P<VariantData>` in `Item_` and `Variant_`
Improvements suggested by @eddyb in https://github.com/rust-lang/rust/pull/28816#discussion_r42483587 and https://github.com/rust-lang/rust/pull/28816#discussion_r42483648
plugin-[breaking-change]
r? @eddyb
|
|
This commit stabilizes and deprecates library APIs whose FCP has closed in the
last cycle, specifically:
Stabilized APIs:
* `fs::canonicalize`
* `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists,
is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait.
* `Formatter::fill`
* `Formatter::width`
* `Formatter::precision`
* `Formatter::sign_plus`
* `Formatter::sign_minus`
* `Formatter::alternate`
* `Formatter::sign_aware_zero_pad`
* `string::ParseError`
* `Utf8Error::valid_up_to`
* `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}`
* `<[T]>::split_{first,last}{,_mut}`
* `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated
but will be once 1.5 is released.
* `str::{R,}MatchIndices`
* `str::{r,}match_indices`
* `char::from_u32_unchecked`
* `VecDeque::insert`
* `VecDeque::shrink_to_fit`
* `VecDeque::as_slices`
* `VecDeque::as_mut_slices`
* `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`)
* `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`)
* `Vec::resize`
* `str::slice_mut_unchecked`
* `FileTypeExt`
* `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}`
* `BinaryHeap::from` - `from_vec` deprecated in favor of this
* `BinaryHeap::into_vec` - plus a `Into` impl
* `BinaryHeap::into_sorted_vec`
Deprecated APIs
* `slice::ref_slice`
* `slice::mut_ref_slice`
* `iter::{range_inclusive, RangeInclusive}`
* `std::dynamic_lib`
Closes #27706
Closes #27725
cc #27726 (align not stabilized yet)
Closes #27734
Closes #27737
Closes #27742
Closes #27743
Closes #27772
Closes #27774
Closes #27777
Closes #27781
cc #27788 (a few remaining methods though)
Closes #27790
Closes #27793
Closes #27796
Closes #27810
cc #28147 (not all parts stabilized)
|
|
And use VariantData instead of P<VariantData> in Item_ and Variant_
|
|
|
|
unwrapping
|
|
|
|
Previously, if you copied a signature from a trait definition such as:
```
fn foo<'a>(&'a Bar) -> bool {}
```
and moved it into an `impl`, there would be an error message:
"unexpected token `'a`"
Adding to the error message that a pattern is expected should help
users to find the actual problem with using a lifetime here.
|
