Logically, it's a vector of pairs, so might as well represent it that
way.
The commit also changes `scan_stack` so that it is initialized with the
default size, instead of the excessive `55 * linewidth` size, which it
usually doesn't get even close to reaching.
`opaque::Decoder::read_str` is very hot within `rustc` due to its use in
the reading of crate metadata, and it currently returns a `String`. This
commit changes it to instead return a `Cow<str>`, which avoids a heap
allocation.
This change reduces the number of calls to `malloc` by almost 10% in
some benchmarks.
This is a [breaking-change] to libserialize.
rustc: Rename rustc_macro to proc_macro
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`,
which reflects the general consensus of #35900. A follow up PR to Cargo will be
required to purge the `rustc-macro` name as well.
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`,
which reflects the general consensus of #35900. A follow up PR to Cargo will be
required to purge the `rustc-macro` name as well.
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.
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
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`.
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 :-)
