Avoid some allocations in the macro parser
These three commits reduce the number of heap allocations done when compiling rustc-benchmarks/html5ever-2016-08-25 by 20%, from 16.5M to 13.3M. This speeds up (debug) compilation of it with a stage1 compiler by about 7%.
Fix line stepping in debugger.
Attribute drop code to block's closing brace, instead of the line where the allocation was done.
Attribute function epilogues to function body's closing brace, rather than the function header.
Fixes#37032
r? @michaelwoerister
remove keys w/ skolemized regions from proj cache when popping skolemized regions
This addresses #37154 (a regression). The projection cache was incorrectly caching the results for skolemized regions -- when we pop skolemized regions, we are supposed to drop cache keys for them (just as we remove those skolemized regions from the region inference graph). This is because those skolemized region numbers will be reused later with different meaning (and we have determined that the old ones don't leak out in any meaningful way).
I did a *somewhat* aggressive fix here of only removing keys that mention the skolemized regions. One could imagine just removing all keys added since we started the skolemization (as indeed I did in my initial commit). This more aggressive fix required fixing a latent bug in `TypeFlags`, as an aside.
I believe the more aggressive fix is correct; clearly there can be entries that are unrelated to the skoelemized region, and it's a shame to remove them. My one concern was that it *is* possible I believe to have some region variables that are created and related to skolemized regions, and maybe some of them could end up in the cache. However, that seems harmless enough to me-- those relations will be removed, and couldn't have impacted how trait resolution proceeded anyway (iow, the cache entry is not wrong, though it is kind of useless).
r? @pnkfelix
cc @arielb1
syntax: Tweak path parsing logic
Associated paths starting with `<<` are parsed in patterns.
Paths like `self::foo::bar` are interpreted as paths and not as `self` arguments in methods (cc @matklad).
Now, I believe, *all* paths are consistently parsed greedily in case of ambiguity.
Detection of `&'a mut self::` requires pretty large (but still fixed) lookahead, so I had to increase the size of parser's lookahead buffer.
Curiously, if `lookahead_distance >= lookahead_buffer_size` was used previously, the parser hung forever, I fixed this as well, now it ICEs.
r? @jseyfried
macros: Future proof `#[no_link]`
This PR future proofs `#[no_link]` for macro modularization (cc #35896).
First, we resolve all `#[no_link] extern crate`s. `#[no_link]` crates without `#[macro_use]` or `#[macro_reexport]` are not resolved today, this is a [breaking-change]. For example,
```rust
```
Any breakage can be fixed by simply removing the `#[no_link] extern crate`.
Second, `#[no_link] extern crate`s will define an empty module in type namespace to eventually allow importing the crate's macros with `use`. This is a [breaking-change], for example:
```rust
mod syntax {} //< This becomes a duplicate error.
```
r? @nrc
Attribute drop code to block's closing brace, instead of the line where the allocation was done.
Attribute function epilogues to function body's closing brace, rather than the function header.
Expand .zip() specialization to .map() and .cloned()
Implement .zip() specialization for Map and Cloned.
The crucial thing for transparent specialization is that we want to
preserve the potential side effects.
The simplest example is that in this code snippet:
`(0..6).map(f).zip((0..4).map(g)).count()`
`f` will be called five times, and `g` four times. The last time for `f`
is when the other iterator is at its end, so this element is unused.
This side effect can be preserved without disturbing code generation for
simple uses of `.map()`.
The `Zip::next_back()` case is even more complicated, unfortunately.
macros: fix partially consumed tokens in macro matchers
Fixes#37175.
This PR also avoids re-transcribing the tokens consumed by a matcher (and cloning the `TtReader` once per matcher), which improves expansion performance of the test case from #34630 by ~8%.
r? @nrc
Fix some pretty printing tests
Many pretty-printing tests are un-ignored.
Some issues in classification of comments (trailing/isolated) and blank line counting are fixed.
Some comments are printed more carefully.
Some minor refactoring in pprust.rs
`no-pretty-expanded` annotations are removed because this is the default now.
`pretty-expanded` annotations are removed from compile-fail tests, they are not tested with pretty-printer.
Closes https://github.com/rust-lang/rust/issues/23623 in favor of more specific https://github.com/rust-lang/rust/issues/37201 and https://github.com/rust-lang/rust/issues/37199
r? @nrc
macros 1.1: future proofing and cleanup
This PR
- uses the macro namespace for custom derives (instead of a dedicated custom derive namespace),
- relaxes the shadowing rules for `#[macro_use]`-imported custom derives to match the shadowing rules for ordinary `#[macro_use]`-imported macros, and
- treats custom derive `extern crate`s like empty modules so that we can eventually allow, for example, `extern crate serde_derive; use serde_derive::Serialize;` backwards compatibly.
r? @alexcrichton
Add AppVeyor configuration to the repo
We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds
an `appveyor.yml` configuration file which is ready to run builds on the auto
branch. This is also accompanied with a few minor fixes to the build system and
such to accomodate AppVeyor.
The intention is that we're not switching over to AppVeyor entirely just yet,
but rather we'll watch the builds for a week or so. If everything checks out
then we'll start gating on AppVeyor instead of Buildbot!
Avoid many CrateConfig clones.
This commit changes `ExtCtx::cfg()` so it returns a `CrateConfig`
reference instead of a clone. As a result, it also changes all of the
`cfg()` callsites to explicitly clone... except one, because the commit
also changes `macro_parser::parse()` to take `&CrateConfig`. This is
good, because that function can be hot, and `CrateConfig` is expensive
to clone.
This change almost halves the number of heap allocations done by rustc
for `html5ever` in rustc-benchmarks suite, which makes compilation 1.20x
faster.
r? @nrc
add test case for changing private methods
The goal of this test case is to ensure we are getting the reuse we expect. This targets a particular change where we modify the body of a private inherent method defined on a struct, and looks at different ways we can use that struct.
It checks for when type-checking would be needed as well as the actual reuse achieved.
cc https://github.com/rust-lang/rust/issues/37121
r? @michaelwoerister
`#[may_dangle]` attribute
`#[may_dangle]` attribute
Second step of #34761. Last big hurdle before we can work in earnest towards Allocator integration (#32838)
Note: I am not clear if this is *also* a syntax-breaking change that needs to be part of a breaking-batch.
Use a distinct error code for "if may be missing an else clause"
Introduce the possibility of assigning distinct error codes to the various origin types of E0308. Start by assigning E0317 for the "IfExpressionWithNoElse" case, and write a long diagnostic specific to this case.
Fixes#36596
This addresses issue pointed out by niko that prior code would break
if the declaration order for generics does not match how they are fed
into the instantiation of the type itself. (Added some tests
exercising this scenario.)
Implement .zip() specialization for Map and Cloned.
The crucial thing for transparent specialization is that we want to
preserve the potential side effects.
The simplest example is that in this code snippet:
`(0..6).map(f).zip((0..4).map(g)).count()`
`f` will be called five times, and `g` four times. The last time for `f`
is when the other iterator is at its end, so this element is unused.
This side effect can be preserved without disturbing code generation for
simple uses of `.map()`.
The `Zip::next_back()` case is even more complicated, unfortunately.
We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds
an `appveyor.yml` configuration file which is ready to run builds on the auto
branch. This is also accompanied with a few minor fixes to the build system and
such to accomodate AppVeyor.
The intention is that we're not switching over to AppVeyor entirely just yet,
but rather we'll watch the builds for a week or so. If everything checks out
then we'll start gating on AppVeyor instead of Buildbot!
Changed error message E0408 to new format
Followed your text and was able to change the ouput to the new format.
I did not encounter any broken test therefore this is a really small commit.
Thanks for letting me hack on the compiler :)
r? @jonathandturner
This commit changes `ExtCtx::cfg()` so it returns a `CrateConfig`
reference instead of a clone. As a result, it also changes all of the
`cfg()` callsites to explicitly clone... except one, because the commit
also changes `macro_parser::parse()` to take `&CrateConfig`. This is
good, because that function can be hot, and `CrateConfig` is expensive
to clone.
This change almost halves the number of heap allocations done by rustc
for `html5ever` in rustc-benchmarks suite, which makes compilation 1.20x
faster.
