| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
AST/HIR: Add a separate structure for labels
|
|
across suspension points to borrowck. Fixes #44197, #45259 and #45093.
|
|
|
|
Introduce a new unified type that holds the expression precedence for
both AST and HIR nodes.
|
|
No longer parse it.
Remove AutoTrait variant from AST and HIR.
Remove backwards compatibility lint.
Remove coherence checks, they make no sense for the new syntax.
Remove from rustdoc.
|
|
Started rebasing @sgrif's PR #33135 off of current master. (Well, actually merging it into a new branch based off current master.)
The following files still need to be fixed or at least reviewed:
- `src/libsyntax/ext/tt/macro_parser.rs`: calls `Parser::parse_lifetime`, which doesn't exist anymore
- `src/libsyntax/parse/parser.rs`: @sgrif added an error message to `Parser::parse_lifetime`. Code has since been refactored, so I just took it out for now.
- `src/libsyntax/ext/tt/transcribe.rs`: This code has been refactored bigtime. Not sure whether @sgrif's changes here are still necessary. Took it out for this commit.
|
|
The Generics now contain one Vec of an enum for the generic parameters,
rather than two separate Vec's for lifetime and type parameters.
Additionally, places that previously used Vec<LifetimeDef> now use
Vec<GenericParam> instead.
|
|
|
|
|
|
|
|
|
|
This commit adds support for nested groups inside `use` declarations,
such as `use foo::{bar, sub::{baz::Foo, *}};`.
|
|
Add error for `...` in expressions
Follow-up to https://github.com/rust-lang/rust/pull/44709
Tracking issue: https://github.com/rust-lang/rust/issues/28237
* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`
r? petrochenkov
|
|
Pretty print parens around casts on the LHS of `<`/`<<`
When pretty printing a cast expression occuring on the LHS of a `<` or `<<` expression, we should add parens around the cast. Otherwise, the `<`/`<<` gets interpreted as the beginning of the generics for the type on the RHS of the cast.
Consider:
$ cat parens_cast.rs
macro_rules! negative {
($e:expr) => { $e < 0 }
}
fn main() {
negative!(1 as i32);
}
Before this PR, the output of the following is not valid Rust:
$ rustc -Z unstable-options --pretty=expanded parens_cast.rs
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
macro_rules! negative(( $ e : expr ) => { $ e < 0 });
fn main() { 1 as i32 < 0; }
After this PR, the output of the following is valid Rust:
$ rustc -Z unstable-options --pretty=expanded parens_cast.rs
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
macro_rules! negative(( $ e : expr ) => { $ e < 0 });
fn main() { (1 as i32) < 0; }
I've gone through several README/wiki style documents but I'm still not sure where to test this though. I'm not even sure if this sort of thing is tested...
|
|
|
|
When pretty printing a cast expression occuring on the LHS of a '<'
or '<<' expression, we should add parens around the cast. Otherwise,
the '<'/'<<' gets interpreted as the beginning of the generics for
the type on the RHS of the cast.
|
|
It was being printed wrong as auto unsafe trait
|
|
Adds an `IsAuto` field to `ItemTrait` which flags if the trait was
declared as an `auto trait`.
Auto traits cannot have generics nor super traits.
|
|
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
|
|
|
|
r=nikomatsakis
`crate` shorthand visibility modifier
cc #45388.
r? @nikomatsakis
|
|
With regrets, this breaks rustfmt and rls.
This is in the matter of #45388.
|
|
support generics in each variant of TraitItem and ImplItem
|
|
|
|
... or ..=
|
|
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
|
|
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The literal index was increased in only next_lit, so it isn't
necessary: code now uses an iterator. The cur_cmnt field is also moved
to be increased in print_comment instead of after each call to
print_comment.
|
|
No (intentional) changes to behavior. This is intended to avoid the
anti-pattern of having to import individual methods throughout code.
|
|
|
|
|
|
|
|
|
|
remove variant `Token::SubstNt` in favor of `quoted::TokenTree::MetaVar`.
|
|
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
|
|
Generates signatures for use in Rustdoc and similar tools.
|
|
|
|
|
|
|
|
|
