| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
r? @alexcrichton
|
|
Avoid confusion with binary integer literals and binary operator expressions in libsyntax
|
|
Fixes #28109
|
|
The spans of break and continue would include the next token.
|
|
Fixes https://github.com/rust-lang/rust/issues/28105.
|
|
|
|
An implementation of [RFC 1219](https://github.com/rust-lang/rfcs/pull/1219).
The RFC is not merged yet, but once merged, this could be.
|
|
|
|
Reapplied the changes from https://github.com/freebroccolo/rust/commit/8b07abaa6e8ab42d37656dfad89de0eb5810c3b3
to a clean branch of master
|
|
|
|
|
|
this has quite some fallout. but also made lots of stuff more readable imo
[breaking-change] for plugin authors
|
|
|
|
|
|
`LocalSource` indicated wether a let binding originated from for-loop desugaring to enable specialized error messages, but for-loop expansion has changed and this is now achieved through `MatchSource::ForLoopDesugar`.
|
|
Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol.
Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].)
[RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
Part of #22181
Replaced PR #26180.
Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`.
(Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.)
----
Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
|
|
Right trims the span for certain range expressions.
Closes https://github.com/rust-lang/rust/issues/27162.
|
|
|
|
|
|
|
|
This basically only affects modules which are empty (or only contain comments).
Closes #26755
|
|
|
|
This makes the functionality usable from outside the parser
|
|
|
|
|
|
This makes the functionality usable from outside the parser
|
|
Pull request for #26188.
|
|
|
|
Using two terms for one thing is confusing, these are called 'raw pointers' today.
|
|
Issue: #26083
Re-submitting https://github.com/rust-lang/rust/pull/26084
r? @nrc
|
|
|
|
|
|
|
|
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
|
|
|
|
This allows compiling entire crates from memory or preprocessing source files before they are tokenized.
Minor API refactoring included, which is a [breaking-change] for libsyntax users:
* `ParseSess::{next_node_id, reserve_node_ids}` moved to rustc's `Session`
* `new_parse_sess` -> `ParseSess::new`
* `new_parse_sess_special_handler` -> `ParseSess::with_span_handler`
* `mk_span_handler` -> `SpanHandler::new`
* `default_handler` -> `Handler::new`
* `mk_handler` -> `Handler::with_emitter`
* `string_to_filemap(sess source, path)` -> `sess.codemap().new_filemap(path, source)`
|
|
Closes #25468.
|
|
Closes #25468.
|
|
Closes #24986.
|
|
|
|
|
|
|
|
It is currently broken to use syntax such as `<T as Foo>::U::static_method()` where `<T as Foo>::U` is an associated type. I was able to fix this and simplify the parser a bit at the same time.
This also fixes the corresponding issue with associated types (#22139), but that's somewhat irrelevant because #22519 is still open, so this syntax still causes an error in type checking.
Similarly, although this fix applies to associated consts, #25046 forbids associated constants from using type parameters or `Self`, while #19559 means that associated types have to always have one of those two. Therefore, I think that you can't use an associated const from an associated type anyway.
|
|
|
|
|
|
Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (#13547, #8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)).
One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! :fallen_leaf: :ocean:
|
|
|
|
|
