| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Properly feature gate all unstable ABIs
Fixes https://github.com/rust-lang/rust/issues/34900
[breaking-change]
r? @pnkfelix
---
Function-visiting machinery for AST/HIR is surprisingly error-prone, it's *very* easy to miss some cases or visit something twice while writing a visitor. This is the true problem behind https://github.com/rust-lang/rust/issues/34900. I'll try to restructure these visitors a bit and send one more PR later.
|
|
Better attribute and metaitem encapsulation throughout the compiler
This PR refactors most (hopefully all?) of the `MetaItem` interactions outside of `libsyntax` (and a few inside) to interact with MetaItems through the provided traits instead of directly creating / destruct / matching against them. This is a necessary first step to eventually converting `MetaItem`s to internally use `TokenStream` representations (which will make `MetaItem` interactions much nicer for macro writers once the new macro system is in place).
r? @nrc
|
|
Enable reuse of `.o` files if nothing has changed
This PR completes a first "spike" for incremental compilation by enabling us to reuse `.o` files when nothing has changed. When in incr. mode, we will save `.o` files into the temporary directory, then copy them back out again if they are still valid. The code is still a bit rough but it does seem to work. =)
r? @michaelwoerister
Fixes #34036
Fixes #34037
Fixes #34038
|
|
|
|
Avoid processing `feature`s on unconfigured crates
Fixes #34932, a regression caused by #34272.
r? @nrc
|
|
|
|
|
|
|
|
Support nested `macro_rules!`
Fixes #6994.
r? @eddyb
|
|
|
|
|
|
|
|
|
|
macros: fix bug in `stmt` matchers
Today, `stmt` matchers stop too early when parsing expression statements that begin with non-braced macro invocations. For example,
```rust
fn main() {
macro_rules! m { ($s:stmt;) => { $s } }
id!(vec![].push(0););
//^ Before this PR, the `stmt` matcher only consumes "vec![]", so this is an error.
//| After this PR, the `stmt` matcher consumes "vec![].push(0)", so this compiles.
}
```
This change is backwards compatible due to the follow set for `stmt`.
r? @eddyb
|
|
Clean up and encapsulate `syntax::ext::mtwt`, rename `mtwt` to `hygiene`
r? @nrc
|
|
and that would be painful to rewrite.
|
|
|
|
|
|
|
|
Added tokenstream parser procedure
A tiny PR that simply adds a procedure for parsing `TokenStream`s to the parser in `src/libsyntax`. This is to ease using `TokenStream`s with the current (old) procedural macro system.
|
|
Simplify librustc_errors
This is part 2 of the error crate refactor, starting with #34403.
In this refactor, I focused on slimming down the error crate to fewer moving parts. As such, I've removed quite a few parts and replaced the with simpler, straight-line code. Specifically, this PR:
* Removes BasicEmitter
* Remove emit from emitter, leaving emit_struct
* Renames emit_struct to emit
* Removes CoreEmitter and focuses on a single Emitter
* Implements the latest changes to error format RFC (#1644)
* Removes (now-unused) code in emitter.rs and snippet.rs
* Moves more tests to the UI tester, removing some duplicate tests in the process
There is probably more that could be done with some additional refactoring, but this felt like it was getting to a good state.
r? @alexcrichton cc: @Manishearth (as there may be breaking changes in stuff I removed/changed)
|
|
Fix `include!()`s inside `asm!()` invocations
Fixes #34812, a regression caused by #33749 that was not fixed in #34450.
r? @nrc
|
|
Better error message for inner attribute following doc comment
Before it was always just "an inner attribute is not permitted in this context", whereas now we add a special case for when an inner attr follows an outer attr. If the outer attr is a doc comment, then the error is "an inner attr is not permitted following a doc comment", and otherwise it's "an inner attr is not permitted following an outer attribute". In all other cases it's still "an inner attribute is not permitted in this context".
Note that the public API and behaviour of `parse_attribute` is unchanged. Also, all new names are very open to bikeshedding -- they're arguably clunky.
Fixes #34516. cc @brson
|
|
|
|
|
|
Simplify the macro hygiene algorithm
This PR removes renaming from the hygiene algorithm and treats differently marked identifiers as unequal.
This change makes the scope of identifiers in `macro_rules!` items empty. That is, identifiers in `macro_rules!` definitions do not inherit any semantics from the `macro_rules!`'s scope.
Since `macro_rules!` macros are items, the scope of their identifiers "should" be the same as that of other items; in particular, the scope should contain only items. Since all items are unhygienic today, this would mean the scope should be empty.
However, the scope of an identifier in a `macro_rules!` statement today is the scope that the identifier would have if it replaced the `macro_rules!` (excluding anything unhygienic, i.e. locals only).
To continue to support this, this PR tracks the scope of each `macro_rules!` and uses it in `resolve` to ensure that an identifier expanded from a `macro_rules!` gets a chance to resolve to the locals in the `macro_rules!`'s scope.
This PR is a pure refactoring. After this PR,
- `syntax::ext::expand` is much simpler.
- We can expand macros in any order without causing problems for hygiene (needed for macro modularization).
- We can deprecate or remove today's `macro_rules!` scope easily.
- Expansion performance improves by 25%, post-expansion memory usage decreases by ~5%.
- Expanding a block is no longer quadratic in the number of `let` statements (fixes #10607).
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
invocations
|
|
|
|
|
|
|
|
|
|
Start cleaning up the string interner
r? @eddyb
|
|
Fix bugs in macro-expanded statement parsing
Fixes #34543.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m { () => {
println!("") println!("")
//^ Semicolons are now required on macro-expanded non-braced macro invocations
//| in statement positions.
let x = 0
//^ Semicolons are now required on macro-expanded `let` statements
//| that are followed by more statements, so this would break.
let y = 0 //< (this would still be allowed to reduce breakage in the wild)
}
fn main() { m!() }
```
r? @eddyb
|
|
|
|
|
|
statements:
```rust
macro_rules! m { () => { let x = 1; x } }
macro_rules! n { () => {
m!() //< This can now expand into statements
}}
fn main() { n!(); }
```
and revert needless fallout fixes.
|
|
|
|
|
|
|
