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 reading this, the comment made it difficult for me to simply absorb the concept. It interrupted my reading flow, and I think this expresses the same meaning, but reads a bit better.
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.
s390x's C ABI ty_align and ty_size are not moved because the
implementation of ty_align varies in an atypical pattern: it calls
ty_size for the llvm::Vector type kind. ty_size then cannot be moved
since it indirectly calls ty_align through align.
[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.
This is about the gray area at the top of a trait's documentation page,
that lists all methods and their signatures. A big trait page like
Iterator is very crowded without this tweak.
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.
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.
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
