| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is a [breaking-change] for libsyntax.
|
|
Likewise, rename LastTokenKind as PrevTokenKind.
This is a [breaking-change] for libsyntax.
|
|
This is a [breaking-change] for libsyntax.
|
|
Two lexer tweaks
19 days later, I haven't received a review of my commits in #36470. In an attempt to make some progress, I'm going to split up the changes. Here are the ones that don't relate to renaming things.
|
|
Enforce the shadowing restrictions from RFC 1560 for today's macros
This PR enforces a weakened version of the shadowing restrictions from RFC 1560. More specifically,
- If a macro expansion contains a `macro_rules!` macro definition that is used outside of the expansion, the defined macro may not shadow an existing macro.
- If a macro expansion contains a `#[macro_use] extern crate` macro import that is used outside of the expansion, the imported macro may not shadow an existing macro.
This is a [breaking-change]. For example,
```rust
macro_rules! m { () => {} }
macro_rules! n { () => {
macro_rules! m { () => {} } //< This shadows an existing macro.
m!(); //< This is inside the expansion that generated `m`'s definition, so it is OK.
} }
n!();
m!(); //< This use of `m` is outside the expansion, so it causes the shadowing to be an error.
```
r? @nrc
|
|
The two branches of this `if` compute the same value. This commit gets
rid of the first branch, which makes this calculation identical to the
one in scan_block_comment().
|
|
First, assert! is redundant w.r.t. the unwrap() immediately afterwards.
Second, `byte_offset_diff` is effectively computed as
`current_byte_offset + ch.len_utf8() - current_byte_offset` (with `next`
as an intermediate) which is silly and can be simplified.
|
|
|
|
`u32`.
|
|
First step for #34761
|
|
jonas-schievink:whats-a-pirates-favorite-data-structure, r=pnkfelix
Contains a syntax-[breaking-change] as a separate commit (cc #31645).nnAlso renames slice patterns from `PatKind::Vec` to `PatKind::Slice`.
|
|
This commit makes the return type of AstBuilder.stmt_let_typed match the return type of other AstBuilder.stmt* functions. This avoids unnecessary boxing/unboxing whenever Stmt's are stored in a Vec, which is the default use case.nnThis is a potentially plugin breaking change.
|
|
Allow more non-inline modules in blocks
Currently, non-inline modules without a `#[path]` attribute are not allowed in blocks.
This PR allows non-inline modules that have an ancestor module with a `#[path]` attribute, provided there is not a nearer ancestor block.
For example,
```rust
fn main() {
#[path = "..."] mod foo {
mod bar; //< allowed by this PR
fn f() {
mod bar; //< still an error
}
}
}
```
Fixes #36772.
r? @nikomatsakis
|
|
Avoid re-export errors in the generated test harness
Fixes #36768.
r? @nrc
|
|
Allow supplying an error destination via the compiler driver
Allows replacing stderr with a buffer from the client.
Also, some refactoring around run_compiler.
|
|
|
|
This applies the HIR changes from the previous commits to the AST, and
is thus a syntax-[breaking-change]
Renames `PatKind::Vec` to `PatKind::Slice`, since these are called slice
patterns, not vec patterns. Renames `TyKind::Vec`, which represents the
type `[T]`, to `TyKind::Slice`. Renames `TyKind::FixedLengthVec` to
`TyKind::Array`.
|
|
Allows replacing stderr with a buffer from the client.
Also, some refactoring around run_compiler.
|
|
Assign def ids and build the module graph during expansion
r? @nrc
|
|
|
|
and expand the `__test_reexports` in the correct scope.
|
|
|
|
Rollup of 14 pull requests
- Successful merges: #36563, #36574, #36586, #36662, #36663, #36669, #36676, #36721, #36723, #36727, #36729, #36742, #36754, #36756
- Failed merges:
|
|
Haiku: Initial work at OS support
These changes should be non-invasive to non-Haiku platforms. These patches were hand reworked from Neil's original Rust 1.9.0 patches. I've done some style cleanup and design updates along the way.
There are a few small additional patches to libc, rust-installer and compiler-rt that will be submitted once this one is accepted.
Haiku can be compiled on Linux, and a full gcc cross-compiler with a Haiku target is available, which means bootstrapping should be fairly easy. The patches here have already successfully bootstrapped under our haiku x86_gcc2 architecture. http://rust-on-haiku.com/wiki/PortingRust
I'll be focusing on our more modern gcc5 x86 and x86 architectures for now.
As for support, we're not seeking official support for now. We understand Haiku isn't a top-tier OS choice, however having these patches upstream greatly reduces the amount of patchwork we have to do. Mesa has Haiku code upstream, and we submit patches to keep it going. Mesa doesn't test on Haiku and we're ok with that :-)
|
|
reject macros with empty repetitions
Fixes #5067 by checking the lhs of `macro_rules!` for repetitions which could match an empty token tree.
|
|
Unify `TokResult` and `ResultAnyMacro`
Fixes #36641.
r? @nrc
|
|
parser: support paths in bang macro invocations (e.g. `path::to::macro!()`)
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Load macros from `#[macro_use]` extern crates in `resolve`
r? @nrc
|
|
* Hand rebased from Niels original work on 1.9.0
|
|
|
|
`ExtCtxt`.
|
|
|
|
binding in generics.
|
|
I am using `ThinAttributes` rather than a vector for attributes
attached to generics, since I expect almost all lifetime and types
parameters to not carry any attributes.
|
|
|
|
|
|
|
|
|
|
resolve: groundwork for building the module graph during expansion
r? @nrc
|
|
Adds a `ProcMacro` form of syntax extension
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too.
Supports both attribute-like and function-like macros.
Note that RFC #1566 has not been accepted yet, but I think there is consensus that we want to head in vaguely that direction and so this PR will be useful in any case. It is also fairly easy to undo and does not break any existing programs.
This is related to #35957 in that I hope it can be used in the implementation of macros 1.1, however, there is no direct overlap and is more of a complement than a competing proposal. There is still a fair bit of work to do before the two can be combined.
r? @jseyfried
cc @alexcrichton, @cgswords, @eddyb, @aturon
|
|
|
