This commit avoids the `fold_regions` call in `plug_leaks` when
`skol_map` is empty, which is the common case. This gives speed-ups of
up to 1.14x on some of the rustc-benchmarks.
Don't allocate during default HashSet creation.
The following `HashMap` creation functions don't allocate heap storage for elements.
```
HashMap::new()
HashMap::default()
HashMap::with_hasher()
```
This is good, because it's surprisingly common to create a HashMap and never
use it. So that case should be cheap.
However, `HashSet` does not have the same behaviour. The corresponding creation
functions *do* allocate heap storage for the default number of non-zero
elements (which is 32 slots for 29 elements).
```
HashMap::new()
HashMap::default()
HashMap::with_hasher()
```
This commit gives `HashSet` the same behaviour as `HashMap`, by simply calling
the corresponding `HashMap` functions (something `HashSet` already does for
`with_capacity` and `with_capacity_and_hasher`). It also reformats one existing
`HashSet` construction to use a consistent single-line format.
This speeds up rustc itself by 1.01--1.04x on most of the non-tiny
rustc-benchmarks.
The following `HashMap` creation functions don't allocate heap storage for elements.
```
HashMap::new()
HashMap::default()
HashMap::with_hasher()
```
This is good, because it's surprisingly common to create a HashMap and never
use it. So that case should be cheap.
However, `HashSet` does not have the same behaviour. The corresponding creation
functions *do* allocate heap storage for the default number of non-zero
elements (which is 32 slots for 29 elements).
```
HashMap::new()
HashMap::default()
HashMap::with_hasher()
```
This commit gives `HashSet` the same behaviour as `HashMap`, by simply calling
the corresponding `HashMap` functions (something `HashSet` already does for
`with_capacity` and `with_capacity_and_hasher`). It also reformats one existing
`HashSet` construction to use a consistent single-line format.
This speeds up rustc itself by 1.01--1.04x on most of the non-tiny
rustc-benchmarks.
refactor to remove trans::adt and make rustc::ty::layout authoritative
I asked on IRC about optimizing struct layout by reordering fields from most-aligned to least-aligned and somehow ended up getting talked into doing this. The goal here is to make `layout` authoritative and to remove `adt`. The former has been accomplished by reimplementing `represent_type_uncached` and the latter is in progress. @eddyb thought I should make the PR now.
My plan is to reserve the actual optimization for a second PR, as this work is useful by itself.
rustbuild: Nicer error for host builds of targets
If a triple is configured only as a target, not a host, then trying to build
that triple with host artifacts would cause a panic. Fail a little nicer
instead.
Closes#36268
Skip binary tidy check when on Windows Linux Subsystem
While it's possible that other linux systems will include "Microsoft" in
their /proc/version, this is deemed unlikely, and since this is a tidy
check, will likely be caught by buildbot/travis either way.
Fixes#36706.
While it's possible that other linux systems will include "Microsoft" in
their /proc/version, this is deemed unlikely, and since this is a tidy
check, will likely be caught by buildbot/travis either way.
[breaking-change] Remove TypedArena::with_capacity
This is a follow-up to #36592.
The function is unused by rustc. Also, it doesn't really follow the
usual meaning of a `with_capacity` function because the first chunk
allocation is now delayed until the first `alloc` call.
This change reduces the size of `TypedArena` by one `usize`.
@eddyb: we discussed this on IRC. Would you like to review it?
Fix a variety of minor issues
CSS:
- use integer values for font-size in CSS
- use correct ordering of @import
- "invisible" isn't a tag - presume its a class
- "border-color" defines the complete border
python:
- use "not" instead of == "[]" for python
- prefer triple quoted docstrings
- prefer static functions where possible
- prefer modern style classes where possible
- remove semicolons;
global:
- remove duplicated words words
Fix wording for out-of-crate macro error
This fixes the wording of the note for out-of-crate macro errors to fix https://github.com/rust-lang/rust/issues/36469
The previous wording came from older logic in the PR that was replaced without updating the note.
Don't let a type parameter named "Self" unchanged past HIR lowering.
Fixes#36638 by rewriting `Self` type parameters (which are a parse error) to a `gensym("Self")`.
Background: #35605 introduced code across rustc that determines `Self` by its keyword name.
Reverting the sanity checks around that would inadvertently cause confusion between the true `Self` of a `trait` and other type parameters named `Self` (which have caused parse errors already).
I do not like to use `gensym`, and we may do something different here in the future, but this should work.
Fix ICE test in compiletest fail-tests
While working on Clippy which uses *compiletest*, I noticed that as long as all expected error are found, *compile-fail* tests will be marked *ok* even if there is an ICE. One function seems to have not been updated with JSON errors because ICEs are now reported like this:
```json
{"message":"../src/librustc/ty/context.rs:161: Attempted to intern `_` which contains inference types/regions in the global type context","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":null}
```
I don't think I can add a test for that.
I guess:
r? @nikomatsakis
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
