Commit Graph

2322 Commits

Author SHA1 Message Date
Jeffrey Seyfried
ac1a1d32f6 Allow MultiItemModifiers to expand into zero or many items 2016-06-16 03:55:55 +00:00
Jeffrey Seyfried
34191ed1c8 Refactor MultiModifier expansion 2016-06-16 03:55:53 +00:00
Jeffrey Seyfried
6ba7b7c22d Implement HasAttrs for Annotatable 2016-06-16 03:55:52 +00:00
bors
bf84f4e171 Auto merge of #33749 - jseyfried:fix_call_site_span, r=nrc
Fix macro call site spans

Fix macro call site spans.
r? @nrc
2016-06-13 21:07:30 -07:00
Jeffrey Seyfried
66b9ade341 Strip #[test] nodes during cfg processing on non-test builds. 2016-06-11 03:13:44 +00:00
Jeffrey Seyfried
dbf0326ddc Add comment and clean up expand_annotatable 2016-06-09 00:49:42 +00:00
Jeffrey Seyfried
51499b6e1f Load macros from extern crates during expansion. 2016-06-09 00:44:17 +00:00
bors
ff1315591f Auto merge of #34010 - jseyfried:decorate_expanded, r=nrc
Run decorators on expanded AST

Fixes #32950.
r? @nrc
2016-06-08 02:05:38 -07:00
bors
371bf0eda2 Auto merge of #33982 - LeoTestard:remove-check-matcher-old, r=pnkfelix
Remove the old FOLLOW checking (aka `check_matcher_old`).

It was supposed to be removed at the next release cycle but is still in the tree since like 6 months.
Potential breaking change, since some cases (such as #25658) will change from a warning to an error. But the warning stating that it will be a hard error in the next release has been there for 6 months now.
I think it's safe to break this code. ^_^
2016-06-07 17:56:35 -07:00
Leo Testard
4dab8ae64e Remove the old FOLLOW checking (aka check_matcher_old). 2016-06-06 12:27:34 +02:00
bors
12238b984a Auto merge of #33816 - nikomatsakis:projection-cache-2, r=arielb1
Projection cache and better warnings for #32330

This PR does three things:

- it lays the groundwork for the more precise subtyping rules discussed in #32330, but does not enable them;
- it issues warnings when the result of a leak-check or subtyping check relies on a late-bound region which will late become early-bound when #32330 is fixed;
- it introduces a cache for projection in the inference context.

I'm not 100% happy with the approach taken by the cache here, but it seems like a step in the right direction. It results in big wins on some test cases, but not as big as previous versions -- I think because it is caching the `Vec<Obligation>` (whereas before I just returned the normalized type with an empty vector). However, that change was needed to fix an ICE in @alexcrichton's future-rs module (I haven't fully tracked the cause of that ICE yet). Also, because trans/the collector use a fresh inference context for every call to `fulfill_obligation`, they don't profit nearly as much from this cache as they ought to.

Still, here are the results from the future-rs `retry.rs`:

```
06:26 <nmatsakis> time: 6.246; rss: 44MB  item-bodies checking
06:26 <nmatsakis> time: 54.783; rss: 63MB   translation item collection
06:26 <nmatsakis> time: 140.086; rss: 86MB    translation

06:26 <nmatsakis> time: 0.361; rss: 46MB  item-bodies checking
06:26 <nmatsakis> time: 5.299; rss: 63MB    translation item collection
06:26 <nmatsakis> time: 12.140; rss: 86MB translation
```

~~Another example is the example from #31849. For that, I get 34s to run item-bodies without any cache. The version of the cache included here takes 2s to run item-bodies type-checking. An alternative version which doesn't track nested obligations takes 0.2s, but that version ICEs on @alexcrichton's future-rs (and may well be incorrect, I've not fully convinced myself of that). So, a definite win, but I think there's definitely room for further progress.~~

Pushed a modified version which improves performance of the case from #31849:

```
lunch-box. time rustc --stage0 ~/tmp/issue-31849.rs  -Z no-trans
real    0m33.539s
user    0m32.932s
sys     0m0.570s
lunch-box. time rustc --stage2 ~/tmp/issue-31849.rs  -Z no-trans
real    0m0.195s
user    0m0.154s
sys     0m0.042s
```

Some sort of cache is also needed for unblocking further work on lazy normalization, since that will lean even more heavily on the cache, and will also require cycle detection.

r? @arielb1
2016-06-04 10:47:55 -07:00
Jeffrey Seyfried
58d7e1bf70 Remove redundant check_for_macros AST pass. 2016-06-01 18:51:35 +00:00
Jeffrey Seyfried
dc5cc1b1f2 Run decorators on expanded AST. 2016-06-01 11:12:38 +00:00
Manish Goregaokar
4721f3a543 Rollup merge of #33841 - LeoTestard:macro-sequence-lhs, r=pnkfelix
Reject a LHS formed of a single sequence TT during `macro_rules!` checking.

This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.

Follow up to #33689.

r? @pnkfelix

Note: this can break code that defines such macros but does not use them.
2016-06-01 12:57:41 +05:30
Niko Matsakis
75543c08c7 simplify HR subtyping back to what we did before
A lot of the refactors, however, seem helpful, so leave those in,
particularly since we may want to make this change in the future.
2016-05-31 19:42:22 -04:00
Jeffrey Seyfried
4259fba7e6 Fix macro call site spans 2016-05-28 05:22:16 +00:00
bors
8b012ed142 Auto merge of #33706 - jseyfried:refactor_cfg, r=nrc
Perform `cfg` attribute processing during macro expansion and fix bugs

This PR refactors `cfg` attribute processing and fixes bugs. More specifically:
 - It merges gated feature checking for stmt/expr attributes, `cfg_attr` processing, and `cfg` processing into a single fold.
  - This allows feature gated `cfg` variables to be used in `cfg_attr` on unconfigured items. All other feature gated attributes can already be used on unconfigured items.
 - It performs `cfg` attribute processing during macro expansion instead of after expansion so that macro-expanded items are configured the same as ordinary items. In particular, to match their non-expanded counterparts,
  - macro-expanded unconfigured macro invocations are no longer expanded,
  - macro-expanded unconfigured macro definitions are no longer usable, and
  - feature gated `cfg` variables on macro-expanded macro definitions/invocations are now errors.

This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m {
    () => {
        #[cfg(attr)]
        macro_rules! foo { () => {} }
        foo!(); // This will be an error

        macro_rules! bar { () => { fn f() {} } }
        #[cfg(attr)] bar!(); // This will no longer be expanded ...
        fn g() { f(); } // ... so that `f` will be unresolved.

        #[cfg(target_thread_local)] // This will be a gated feature error
        macro_rules! baz { () => {} }
    }
}

m!();
```

r? @nrc
2016-05-27 17:46:14 -07:00
Manish Goregaokar
7905452f08 Rollup merge of #33644 - petrochenkov:selfast, r=nrc
The AST part of https://github.com/rust-lang/rust/pull/33505.
https://github.com/rust-lang/rust/pull/33505 isn't landed yet, so this PR is based on top of it.

r? @nrc

plugin-[breaking-change] cc #31645 @Manishearth
2016-05-27 09:57:11 +05:30
Manish Goregaokar
35785712cd Rollup merge of #33639 - petrochenkov:dotdot, r=nmatsakis
cc https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis

plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645 @Manishearth
2016-05-27 09:57:00 +05:30
Manish Goregaokar
a70880fea9 Rollup merge of #33351 - birkenfeld:loop-label-spans, r=pnkfelix
This makes the \"shadowing labels\" warning *not* print the entire loop as a span, but only the lifetime.

Also makes #31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).
2016-05-27 09:56:47 +05:30
Jeffrey Seyfried
0558df24af Refactor expand_expr 2016-05-27 00:01:04 +00:00
Jeffrey Seyfried
1aa34e0b5f Strip unconfigured items during macro expansion 2016-05-27 00:01:04 +00:00
Jeffrey Seyfried
25c733360b Update spans' expn_id during the marking fold 2016-05-27 00:01:04 +00:00
Leo Testard
864b3c8017 Reject a LHS formed of a single sequence TT during macro_rules! checking.
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
2016-05-26 19:05:44 +02:00
bors
dc91467db0 Auto merge of #33766 - jseyfried:cleanup_expansion, r=nrc
Cleanup macro expansion and improve diagnostics

Cleanup macro expansion and improve diagnostics. Fixes #33709.
r? @nrc
2016-05-26 08:32:21 -07:00
Vadim Petrochenkov
d69aeaf662 Implement .. in tuple (struct) patterns 2016-05-26 11:11:58 +03:00
Vadim Petrochenkov
1a1de5bf89 Add a new AST-only type variant ImplicitSelf 2016-05-25 21:55:04 +03:00
Vadim Petrochenkov
5660a00486 Remove ExplicitSelf from AST 2016-05-25 21:55:04 +03:00
bors
da66f2fd8c Auto merge of #33713 - LeoTestard:macro-rules-invalid-lhs, r=pnkfelix
Make sure that macros that didn't pass LHS checking are not expanded.

This avoid duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros.
2016-05-25 09:40:06 -07:00
Georg Brandl
2e812e10f4 syntax/hir: give loop labels a span
This makes the "shadowing labels" warning *not* print the entire loop
as a span, but only the lifetime.

Also makes #31719 go away, but does not fix its root cause (the span
of the expanded loop is still wonky, but not used anymore).
2016-05-24 14:22:14 +02:00
Jeffrey Seyfried
e9c0283369 Add comments and fix a nit 2016-05-24 11:48:00 +00:00
Leo Testard
7d521445fd Avoid iterating two times over the list of LHSes. 2016-05-24 11:21:37 +02:00
Leo Testard
eb364e9c29 Make sure that macros that didn't pass LHS checking are not expanded.
This avoids duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros. Fixes #29231.
2016-05-24 11:21:28 +02:00
Jeffrey Seyfried
ba8b9324d6 Move placement_in_syntax gated feature checking from expansion to the post-expansion visitor 2016-05-21 23:02:34 +00:00
Jeffrey Seyfried
82b49cd200 Refactor away check_attributes 2016-05-21 23:01:02 +00:00
Jeffrey Seyfried
a3d705ef30 Refactor away expand_item_mac 2016-05-21 23:01:02 +00:00
Jeffrey Seyfried
3192adbf87 Refactor out mac_result in expand_mac_invoc 2016-05-21 23:01:02 +00:00
Jeffrey Seyfried
215c1460f6 Check attributes in expand_mac_invoc 2016-05-21 23:01:02 +00:00
Jeffrey Seyfried
f4075e9467 Use expand_mac_invoc in expand_pat 2016-05-21 23:01:01 +00:00
Jeffrey Seyfried
8ee93b73d1 Re-fold expanded items in expand_mac_invoc 2016-05-21 23:01:01 +00:00
Jeffrey Seyfried
2e7afd7367 Improve diagnostics 2016-05-21 23:01:01 +00:00
Jeffrey Seyfried
7f30eef2ee Introduce MacroGenerable trait 2016-05-21 23:00:57 +00:00
Jeffrey Seyfried
f630419351 Fix bug in macro expression spans 2016-05-18 11:46:08 +00:00
Alex Crichton
0ec321f7b5 rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-05-09 08:22:36 -07:00
Niko Matsakis
489a6c95bf replace fileline_{help,note} with {help,note}
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.
2016-05-02 11:49:23 -04:00
Niko Matsakis
1ff1887cc9 thread tighter span for closures around
Track the span corresponding to the `|...|` part of the closure.
2016-05-02 11:47:10 -04:00
bors
b0aefff714 Auto merge of #32846 - jseyfried:allow_unconfigured_gated_expanded_items, r=nrc
Avoid gated feature checking unconfigured expanded items

Avoid gated feature checking unconfigured macro-expanded items (fixes #32840).
Unconfigured items that are not macro-expanded are already not gated feature checked.
r? @nrc
2016-04-30 02:07:33 -07:00
bors
435095f32a Auto merge of #32791 - LeoTestard:feature-gate-clean, r=nikomatsakis
Feature gate clean

This PR does a bit of cleaning in the feature-gate-handling code of libsyntax. It also fixes two bugs (#32782 and #32648). Changes include:

* Change the way the existing features are declared in `feature_gate.rs`. The array of features and the `Features` struct are now defined together by a single macro. `featureck.py` has been updated accordingly. Note: there are now three different arrays for active, removed and accepted features instead of a single one with a `Status` item to tell wether a feature is active, removed, or accepted. This is mainly due to the way I implemented my macro in the first time and I can switch back to a single array if needed. But an advantage of the way it is now is that when an active feature is used, the parser only searches through the list of active features. It goes through the other arrays only if the feature is not found. I like to think that error checking (in this case, checking that an used feature is active) does not slow down compilation of valid code. :) But this is not very important...
* Feature-gate checking pass now use the `Features` structure instead of looking through a string vector. This should speed them up a bit. The construction of the `Features` struct should be faster too since it is build directly when parsing features instead of calling `has_feature` dozens of times.
* The MacroVisitor pass has been removed, it was mostly useless since the `#[cfg]-stripping` phase happens before (fixes #32648). The features that must actually be checked before expansion are now checked at the time they are used. This also allows us to check attributes that are generated by macro expansion and not visible to MacroVisitor, but are also removed by macro expansion and thus not visible to PostExpansionVisitor either. This fixes #32782. Note that in order for `#[derive_*]` to be feature-gated but still accepted when generated by `#[derive(Trait)]`, I had to do a little bit of trickery with spans that I'm not totally confident into. Please review that part carefully. (It's in `libsyntax_ext/deriving/mod.rs`.)::

Note: this is a [breaking change], since programs with feature-gated attributes on macro-generated macro invocations were not rejected before. For example:

```rust
macro_rules! bar (
    () => ()
);

macro_rules! foo (
    () => (
        #[allow_internal_unstable] //~ ERROR allow_internal_unstable side-steps
        bar!();
    );
);
```
foo!();
2016-04-27 18:35:29 -07:00
mitaa
6887202ea3 Make some fatal lexer errors recoverable 2016-04-27 20:48:18 +02:00
Manish Goregaokar
a31658de51
Rollup merge of #33041 - petrochenkov:path, r=nrc,Manishearth
Paths are mostly parsed without taking whitespaces into account, e.g. `std :: vec :: Vec :: new ()` parses successfully, however, there are some special cases involving keywords `super`, `self` and `Self`. For example, `self::` is considered a path start only if there are no spaces between `self` and `::`. These restrictions probably made sense when `self` and friends weren't keywords, but now they are unnecessary.

The first two commits remove this special treatment of whitespaces by removing `token::IdentStyle` entirely and therefore fix https://github.com/rust-lang/rust/issues/14109.
This change also affects naked `self` and `super` (which are not tightly followed by `::`, obviously) they can now be parsed as paths, however they are still not resolved correctly in imports (cc @jseyfried, see `compile-fail/use-keyword.rs`), so https://github.com/rust-lang/rust/issues/29036 is not completely fixed.

The third commit also makes `super`, `self`, `Self` and `static` keywords nominally (before this they acted as keywords for all purposes) and removes most of remaining \"special idents\".

The last commit (before tests) contains some small improvements - some qualified paths with type parameters are parsed correctly, `parse_path` is not used for parsing single identifiers, imports are sanity checked for absence of type parameters - such type parameters can be generated by syntax extensions or by macros when https://github.com/rust-lang/rust/issues/10415 is fixed (~~soon!~~already!).

This patch changes some pretty basic things in `libsyntax`, like `token::Token` and the keyword list, so it's a plugin-[breaking-change].

r? @eddyb
2016-04-25 00:47:44 +05:30