| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This is similar to the libs version, which allow an `issue` field in the
`#[unstable]` attribute.
cc #28244
|
|
This is similar to the libs version, which allow an `issue` field in the
`#[unstable]` attribute.
cc #28244
|
|
per #28168. This is my first contribution. I don't know who to "r?" for source code changes.
|
|
|
|
|
|
This commit is an implementation of [RFC 1212][rfc] which tweaks the behavior of
the `str::lines` and `BufRead::lines` iterators. Both iterators now account for
`\r\n` sequences in addition to `\n`, allowing for less surprising behavior
across platforms (especially in the `BufRead` case). Splitting *only* on the
`\n` character can still be achieved with `split('\n')` in both cases.
The `str::lines_any` function is also now deprecated as `str::lines` is a
drop-in replacement for it.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
Closes #28032
|
|
This commit is an implementation of [RFC 1212][rfc] which tweaks the behavior of
the `str::lines` and `BufRead::lines` iterators. Both iterators now account for
`\r\n` sequences in addition to `\n`, allowing for less surprising behavior
across platforms (especially in the `BufRead` case). Splitting *only* on the
`\n` character can still be achieved with `split('\n')` in both cases.
The `str::lines_any` function is also now deprecated as `str::lines` is a
drop-in replacement for it.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
Closes #28032
|
|
r? @alexcrichton
|
|
Avoid confusion with binary integer literals and binary operator expressions in libsyntax
|
|
Fixes #28109
|
|
r? @nikomatsakis
Trying to land this first stab, which basically just duplicates the AST. Will file issues for the various things I've got in mind to improve.
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/28108.
|
|
The spans of break and continue would include the next token.
|
|
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
|
|
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
|
|
|
|
There is no longer a need for that pattern, since enums are now qualified.
|
|
Fixes https://github.com/rust-lang/rust/issues/28105.
|
|
Fixes https://github.com/rust-lang/rust/issues/28105.
|
|
|
|
This allows marking attributes as whitelisted/crate-only independent of
their feature gate status.
Closes #24213
|
|
|
|
This allows marking attributes as whitelisted/crate-only independent of
their feature gate status.
Closes #24213
|
|
We were using them for every expansion, instead of using `Name`.
Also converted `CompilerExpansion` into an enum so its nicer to use and takes up less space.
Will profile later, but this should be a small improvement in memory usage.
r? @eddyb
|
|
|
|
|
|
There is no longer a need for that pattern, since enums are now qualified.
|
|
Fixes #11766.
|
|
This handles the case where the #[main] function is buried deeper in
the ast than we search for #[test] functions. I'm not sure why one
would want to do that, but since it works in standard compilation it
should also work for tests.
|
|
Fixes #12327.
|
|
Identifying entry points will be useful in --test mode, which is
handled in libsyntax.
|
|
closes #19102
|
|
Since enums are namespaced now, should we also remove the `Fk` prefixes from `FnKind` and remove the reexport? (The reexport must be removed because otherwise it clashes with glob imports containing `ItemFn`). IMO writing `FnKind::Method` is much clearer than `FkMethod`.
|
|
|
|
The methods gave wrong results for TyIs and TyUs, whose suffix len
should be 5 nowadays. But since they were only used for parsing,
and unneeded for that since 606a309d, remove them rather than fixing.
I hope this is ok to do, since all of rustc is considered unstable...
|
|
In the case where there are no paren in the AST, the pretty printer doesn't correctly print binary operations where precedence is concerned. Parenthesis may be missing due to some kind of expansion or manipulation of the AST.
Example:
Pretty printer prints Expr(*, Expr(+, 1, 1), 2) as 1 + 1 * 2, as opposed to (1 + 1) * 2
r? @nrc
|
|
The methods gave wrong results for TyIs and TyUs, whose suffix len
should be 5 nowadays. But since they were only used for parsing,
and unneeded for that since 606a309d, remove them rather than fixing.
|
|
And some small indentation/code style fixes in the macro parser.
|
|
|
|
|
|
This is purposely separate to the "rust-intrinsic" ABI, because these
intrinsics are theoretically going to become stable, and should be fine
to be independent of the compiler/language internals since they're
intimately to the platform.
|
|
This is theoretically a breaking change, but GitHub search turns up no
uses of it, and most non-built-in cfg's are passed via cargo features,
which look like `feature = "..."`, and hence can't overlap.
|
|
|
|
|
|
|
|
This commit turns `#[unstable]` attributes missing an `issue` annotation into a hard error. This will require the libs team to ensure that there's a tracking issue for all unstable features in the standard library.
All existing unstable features have had issues created and they've all been updated. Yay!
Closes #26868
|
|
Just a little code cleanup I was doing as part of another refactoring (which may turn out not to be needed). The main thrust of this is to cleanup the interface to `tydecode.rs` to be less ridiculously repetitive. I also purged the generic "def-id conversion" parameter in favor of a trait object, just to reduce code duplication a bit and make the signatures a bit less messy. I measured the bootstrapping time to build stage2 with these changes, it was identical. (But it'd be easy enough to restore the unboxed closure if we wanted it.)
|
