This change propagates to many locations, but because of the
Macro Exterminator (or, more properly, the invariant that it
protects), macro invocations can't occur downstream of expansion.
This means that in librustc and librustdoc, extracting the
desired field can simply assume that it can't be a macro
invocation. Functions in ast_util abstract over this check.
The new iterator takes a function and produces an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.
Implementation by Kevin Ballard.
The function returns an Unfold iterator producing an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.
* Don't warn about `#[crate_name]` if `--crate-name` is specified
* Don't warn about non camel case identifiers on `#[repr(C)]` structs
* Switch `mode` to `mode_t` in libc.
They used to be one token too long, so you'd see things like
```
rust/rust/test.rs:1:1: 2:2 warning: unused attribute,
rust/rust/test.rs:1 #![foo]
rust/rust/test.rs:2 #![bar]
```
instead of
```
test.rs:1:1: 1:8 warning: unused attribute, #[warn(unused_attribute)] on
by default
test.rs:1 #![foo]
^~~~~~~
```
Our AST definition can include macro invocations, which can expand into all kinds of things. Macro invocations are expanded away during expansion time, and the rest of the compiler doesn't have to deal with them. However, we have no way of enforcing this.
This patch adds two protective mechanisms.
First, it adds a (quick) explicit check that ensures there are no macro invocations remaining in the AST after expansion. Second, it updates the visit and fold mechanisms so that by default, they will not traverse macro invocations. It's easy enough to add this, if desired (it's documented in the source, and examples appear, e.g. in the IdentFinder.
Along the way, I also consulted with @sfackler to refactor the macro export mechanism so that it stores macro text spans in a side table, rather than leaving them in the AST.
If modified, you can safely unmap arbitrary memory. These fields are not
intended to be modified, so read-only accessors are the only ones that are
provided.
Closes#15478
If modified, you can safely unmap arbitrary memory. These fields are not
intended to be modified, so read-only accessors are the only ones that are
provided.
Closes#15478
If ldconfig fails it emits a warning. This is very possible when installing
to a non-system directory, so the warning tries to indicate that it may
not be a problem.
I have noticed some errors and some absences that I considered essential to the usability of rustc in zsh, so I included them and updated some of the man page.
They used to be one token too long, so you'd see things like
```
rust/rust/test.rs:1:1: 2:2 warning: unused attribute,
rust/rust/test.rs:1 #![foo]
rust/rust/test.rs:2 #![bar]
```
instead of
```
test.rs:1:1: 1:8 warning: unused attribute, #[warn(unused_attribute)] on
by default
test.rs:1 #![foo]
^~~~~~~
```
This PR adds a crate-level dashboard summarizing the stability levels of all items for all submodules of the crate.
The information is also written as a json file, intended for consumption by pages like http://huonw.github.io/isrustfastyet/
Along the way, fixes a few bugs in stability tracking and places where rustdoc was not pulling the existing stability data.
Closes#13541
the Macro Exterminator ensures that there are no macro invocations in
an AST. This should help make later passes confident that there aren't
hidden items, methods, expressions, etc.
macros can expand into arbitrary items, exprs, etc. This
means that using a default walker or folder on an AST before
macro expansion is complete will miss things (the things that
the macros expand into). As a partial fence against this, this
commit moves the default traversal of macros into a separate
procedure, and makes the default trait implementation signal
an error. This means that Folders and Visitors can traverse
macros if they want to, but they need to explicitly add an
impl that calls the walk_mac or fold_mac procedure
This should prevent problems down the road.
Per discussion with @sfackler, refactored the expander to
change the way that exported macros are collected. Specifically,
a crate now contains a side table of spans that exported macros
go into.
This has two benefits. First, the encoder doesn't need to scan through
the expanded crate in order to discover exported macros. Second, the
expander can drop all expanded macros from the crate, with the pleasant
result that a fully expanded crate contains no macro invocations (which
include macro definitions).
Instead of generating a separate case (albeit trivial) for each of the N*N cases when comparing two instances of an enum with N variants, this `deriving` uses the strategy outlined here: https://github.com/rust-lang/rust/issues/15375#issuecomment-47994007
In particular, it generates code that looks more like this:
```rust
match (this, that, ...) {
(Variant1, Variant1, Variant1) => ... // delegate Matching on Variant1
(Variant2, Variant2, Variant2) => ... // delegate Matching on Variant2
...
_ => {
let index_tup = {
let idx_this = match this { Variant1 => 0u, Variant2 => 1u, ... };
let idx_that = match that { Variant1 => 0u, Variant2 => 1u, ... };
...
(idx_this, idx_that, ...)
};
... // delegate to catch-all; it can inspect `index_tup` for its logic
}
}
```
While adding a new variant to the `const_nonmatching` flag (and renaming it to `on_nonmatching`) to allow expressing the above (while still allowing one to opt back into the old `O(N^2)` and in general `O(N^K)` (where `K` is the number of self arguments) code generation behavior), I had two realizations:
1. Observation: Nothing except for the comparison derivings (`PartialOrd`, `Ord`, `PartialEq`, `Eq`) were even using the old `O(N^K)` code generator. So after this hypothetically lands, *nothing* needs to use them, and thus that code generation strategy could be removed, under the assumption that it is very unlikely that any `deriving` mode will actually need that level of generality.
2. Observation: The new code generator I am adding can actually be unified with all of the other code generators that just dispatch on the variant tag (they all assume that there is only one self argument).
These two observations mean that one can get rid of the `const_nonmatching` (aka `on_nonmatching`) entirely. So I did that too in this PR.
The question is: Do we actually want to follow through on both of the above observations? I'm pretty sure the second observation is a pure win. But there *might* be someone out there with an example that invalidates the reasoning in the first observation. That is, there might be a client out there with an example of hypothetical deriving mode that wants to opt into the `O(N^K)` behavior. So, if that is true, then I can revise this PR to resurrect the `on_nonmatching` flag and provide a way to access the `O(N^K)` behavior.
The manner in which I choose to squash these commits during a post-review rebase depends on the answer to the above question.
Fix#15375.
Remove the `NonMatchesExplode` variant now that no deriving impl uses it.
Removed `EnumNonMatching` entirely.
Remove now irrelevant `on_matching` field and `HandleNonMatchingEnums` type.
Removed unused `EnumNonMatchFunc` type def.
Drive-by: revise `EnumNonMatchCollapsedFunc` doc.
Made all calls to `expand_enum_method_body` go directly to
`build_enum_match_tuple`.
Alpha-rename `enum_nonmatch_g` back to `enum_nonmatch_f` to reduce overall diff noise.
Inline sole call of `some_ordering_const`.
Inline sole call of `ordering_const`.
Removed a bunch of code that became dead after the above changes.
In the above formulas, `n` is the number of variants, and `k` is the
number of self-args fed into deriving. In the particular case of
interest (namely `PartialOrd` and `Ord`), `k` is always 2, so we are
basically comparing `O(n)` versus `O(n^2)`.
Also, the stage is set for having *all* enum deriving codes go through
`build_enum_match_tuple` and getting rid of `build_enum_match`.
Also, seriously attempted to clean up the code itself. Added a bunch
of comments attempting to document what I learned as I worked through
the original code and adapted it to this new strategy.
In particular, I want authors of deriving modes to understand what
they are opting into (namely quadratic code size or worse) when they
select NonMatchesExplode.
