| Age | Commit message (Collapse) | Author | Lines |
|
Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`.
|
|
Refactor away `ast::Decl`, refactor `ast::Stmt`, and rename `ast::ExprKind::Again` to `ast::ExprKind::Continue`.
|
|
Miscellaneous low priority cleanup in `libsyntax`.
|
|
syntax-[breaking-change] cc #31645
(Only breaking because ast::TokenTree is now tokenstream::TokenTree.)
This pull request refactors TokenTrees into their own file as src/libsyntax/tokenstream.rs, moving them out of src/libsyntax/ast.rs, in order to prepare for an accompanying TokenStream implementation (per RFC 1566).
|
|
This PR refactors the 'errors' part of libsyntax into its own crate (librustc_errors). This is the first part of a few refactorings to simplify error reporting and potentially support more output formats (like a standardized JSON output and possibly an --explain mode that can work with the user's code), though this PR stands on its own and doesn't assume further changes.
As part of separating out the errors crate, I have also refactored the code position portion of codemap into its own crate (libsyntax_pos). While it's helpful to have the common code positions in a separate crate for the new errors crate, this may also enable further simplifications in the future.
|
|
The AST part of https://github.com/rust-lang/rust/pull/34365
plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645
|
|
**syntax-[breaking-change]** cc #31645
New `TraitItemKind::Macro` variant
This change adds support for macro expansion inside trait items by adding the new `TraitItemKind::Macro` and associated parsing code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow `MultiItemModifier`s to expand into zero or many items
Fixes #34223.
r? @nrc
|
|
Modified tests to point to the new file now.
|
|
|
|
|
|
|
|
Perform `cfg` attribute processing on decorator-generated items
Fixes https://users.rust-lang.org/t/unused-attribute-warning-for-custom-derive-attribute/6180.
r? @nrc
|
|
|
|
|
|
Simplify gated cfg checking
r? @nrc
|
|
|
|
Add an abs_path member to FileMap, use it when writing debug info.
Fixes #34179.
When items are inlined from extern crates, the filename in the debug info
is taken from the FileMap that's serialized in the rlib metadata.
Currently this is just FileMap.name, which is whatever path is passed to rustc.
Since libcore and libstd are built by invoking rustc with relative paths,
they wind up with relative paths in the rlib, and when linked into a binary
the debug info uses relative paths for the names, but since the compilation
directory for the final binary, tools trying to read source filenames
will wind up with bad paths. We noticed this in Firefox with source
filenames from libcore/libstd having bad paths.
This change stores an absolute path in FileMap.abs_path, and uses that
if available for writing debug info. This is not going to magically make
debuggers able to find the source, but it will at least provide sensible
paths.
|
|
When items are inlined from extern crates, the filename in the debug info
is taken from the FileMap that's serialized in the rlib metadata.
Currently this is just FileMap.name, which is whatever path is passed to rustc.
Since libcore and libstd are built by invoking rustc with relative paths,
they wind up with relative paths in the rlib, and when linked into a binary
the debug info uses relative paths for the names, but since the compilation
directory for the final binary, tools trying to read source filenames
will wind up with bad paths. We noticed this in Firefox with source
filenames from libcore/libstd having bad paths.
This change stores an absolute path in FileMap.abs_path, and uses that
if available for writing debug info. This is not going to magically make
debuggers able to find the source, but it will at least provide sensible
paths.
|
|
Revert a change in the scope of macros imported from crates to fix a regression
Fixes #34212.
The regression was caused by #34032, which changed the scope of macros imported from extern crates to match the scope of macros imported from modules.
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
reference)
|
|
|
|
Fix macro call site spans
Fix macro call site spans.
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Run decorators on expanded AST
Fixes #32950.
r? @nrc
|
|
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. ^_^
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
A lot of the refactors, however, seem helpful, so leave those in,
particularly since we may want to make this change in the future.
|