| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The extra filename and line was mainly there to keep the indentation
relative to the main snippet; now that this doesn't include
filename/line-number as a prefix, it is distracted.
|
|
|
|
macro
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[breaking-change] if you use any of the changed functions, you'll need to remove a try! or panictry!
|
|
|
|
fixes part of #30197
|
|
Also split out emitters into their own module.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Fixes #1889
|
|
|
|
Part of https://github.com/rust-lang/rust/issues/29935
The deprecation lint is still called "deprecated", so people can continue using `#[allow(deprecated)]` and similar things.
|
|
resolve errors
fixes #5780
|
|
|
|
Just `sed s/_nopanic//g`. Hopefully makes libsyntax a bit more
readable.
|
|
|
|
Just `sed s/_nopanic//g`. Hopefully makes libsyntax a bit more
readable.
|
|
|
|
A set of commits which pushes some panics out of core parser methods, and into users of those parser methods.
|
|
|
|
|
|
Stricter checking of stability attributes + enforcement of their invariants at compile time
(+ removed dead file librustc_front/attr.rs)
I intended to enforce use of `reason` for unstable items as well (it normally presents for new items), but it turned out too intrusive, many older unstable items don't have `reason`s.
r? @aturon
I'm studying how stability works and do some refactoring along the way, so it's probably not the last PR.
|
|
Stricter checking + enforcement of invariants at compile time
|
|
This is a [breaking change].
|
|
r? @nikomatsakis
|
|
|
|
|
|
Make sure Name, SyntaxContext and Ident are passed by value
Make sure Idents don't serve as keys (or parts of keys) in maps, Ident comparison is not well defined
|
|
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 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 pull request implements the functionality for [RFC 873](https://github.com/rust-lang/rfcs/blob/master/text/0873-type-macros.md). This is currently just an update of @freebroccolo's branch from January, the corresponding commits are linked in each commit message.
@nikomatsakis and I had talked about updating the macro language to support a lifetime fragment specifier, and it is possible to do that work on this branch as well. If so we can (collectively) talk about it next week during the pre-RustCamp work week.
|
|
Test case from here: https://github.com/freebroccolo/rust/commit/9e93fef3c0e61836a8b56f727eb7a2e94bb4ca09
|
|
Reapplied the changes from https://github.com/freebroccolo/rust/commit/7aafe24139abc2d1f302bbb166bcaa006f12cf4d
to a clean branch of master
|
|
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
|
|
Even after expansion, the generated expressions still track depth of
such pushes (i.e. how often you have "pushed" without a corresponding
"pop"), and we add a rule that in a context with a positive
`push_unsafe!` depth, it is effectively an `unsafe` block context.
(This way, we can inject code that uses `unsafe` features, but still
contains within it a sub-expression that should inherit the outer
safety checking setting, outside of the injected code.)
This is a total hack; it not only needs a feature-gate, but probably
should be feature-gated forever (if possible).
ignore-pretty in test/run-pass/pushpop-unsafe-okay.rs
|
