| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Save/load incremental compilation dep graph
Contains the code to serialize/deserialize the dep graph to disk between executions. We also hash the item contents and compare to the new hashes. Also includes a unit test harness. There are definitely some known limitations, such as https://github.com/rust-lang/rust/issues/32014 and https://github.com/rust-lang/rust/issues/32015, but I am leaving those for follow-up work.
Note that this PR builds on https://github.com/rust-lang/rust/pull/32007, so the overlapping commits can be excluded from review.
r? @michaelwoerister
|
|
minor: update old comments
No more lifetimes in function types after https://github.com/rust-lang/rust/commit/f945190e6352a1bc965a117569532643319b400f
|
|
|
|
r? @nikomatsakis
Conflicts:
src/librustc_save_analysis/lib.rs
src/libsyntax/ast_util.rs
|
|
|
|
|
|
|
|
[breaking-batch] Add support for `pub(restricted)` syntax in the AST
This PR allows the AST to represent the `pub(restricted)` syntax from RFC 1422 (cc #32409).
More specifically, it makes `ast::Visibility` non-`Copy` and adds two new variants, `Visibility::Crate` for `pub(crate)` and `Visitibility::Restricted { path: P<Path>, id: NodeId }` for `pub(path)`.
plugin-[breaking-change] cc #31645
r? @pnkfelix
|
|
JSON errors: give better spans for SpanEnd errors
|
|
Issue: #32225
|
|
No more lifetimes in function types after
https://github.com/rust-lang/rust/commit/f945190e6352a1bc965a117569532643319b400f
|
|
|
|
|
|
|
|
|
|
rustbuild: Fix dist for non-host targets
The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.
There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.
These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.
The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).
All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.
Closes #32523
|
|
The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.
There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.
These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.
The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).
All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.
Closes #32523
|
|
syntax: Extra diagnostics for `_` used in an identifier position
Closes https://github.com/rust-lang/rust/issues/32501
|
|
|
|
Gate parser recovery via debugflag
Gate parser recovery via debugflag
Put in `-Z continue_parse_after_error`
This works by adding a method, `fn abort_if_no_parse_recovery`, to the
diagnostic handler in `syntax::errors`, and calling it after each
error is emitted in the parser.
(We might consider adding a debugflag to do such aborts in other
places where we are currently attempting recovery, such as resolve,
but I think the parser is the really important case to handle in the
face of #31994 and the parser bugs of varying degrees that were
injected by parse error recovery.)
r? @nikomatsakis
|
|
This works by adding a boolean flag, `continue_after_error`, to
`syntax::errors::Handler` that can be imperatively set to `true` or
`false` via a new `fn set_continue_after_error`.
The flag starts off true (since we generally try to recover from
compiler errors, and `Handler` is shared across all phases).
Then, during the `phase_1_parse_input`, we consult the setting of the
`-Z continue-parse-after-error` debug flag to determine whether we
should leave the flag set to `true` or should change it to `false`.
----
(We might consider adding a debugflag to do such aborts in other
places where we are currently attempting recovery, such as resolve,
but I think the parser is the really important case to handle in the
face of #31994 and the parser bugs of varying degrees that were
injected by parse error recovery.)
|
|
Prevent bumping the parser past the EOF.
Makes `Parser::bump` after EOF into an ICE, forcing callers to avoid repeated EOF bumps.
This ICE is intended to break infinite loops where EOF wasn't stopping the loop.
For example, the handling of EOF in `parse_trait_items`' recovery loop fixes #32446.
But even without this specific fix, the ICE is triggered, which helps diagnosis and UX.
This is a `[breaking-change]` for plugins authors who eagerly eat multiple EOFs.
See https://github.com/docopt/docopt.rs/pull/171 for such an example and the necessary fix.
|
|
melt the ICE when lowering an impossible range
Emit a fatal error instead of panicking when HIR lowering encounters a range with no `end` point.
This involved adding a method to wire up `LoweringContext::span_fatal`.
Fixes #32245 (cc @nodakai).
r? @nrc
|
|
Signed-off-by: NODA, Kai <nodakai@gmail.com>
|
|
|
|
|
|
Some fixes for error recovery in the compiler
|
|
r=pnkfelix
Restrict constants in patterns
This implements [RFC 1445](https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md). The primary change is to limit the types of constants used in patterns to those that *derive* `Eq` (note that implementing `Eq` is not sufficient). This has two main effects:
1. Floating point constants are linted, and will eventually be disallowed. This is because floating point constants do not implement `Eq` but only `PartialEq`. This check replaces the existing special case code that aimed to detect the use of `NaN`.
2. Structs and enums must derive `Eq` to be usable within a match.
This is a [breaking-change]: if you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement
`Eq`. Something like the following:
```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;
match foo {
SOME_CONST => ...
}
```
The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*):
```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;
match foo {
SOME_CONST => ...
}
```
Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`):
```rust
match foo {
c if c == SOME_CONST => ...
}
```
Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC #1445 for more details.
cc https://github.com/rust-lang/rust/issues/31434
r? @pnkfelix
|
|
|
|
this was required to preserve the span from
the #[structural_match] attribute -- but honestly
I am not 100% sure if it makes sense.
|
|
to careful use of the span from deriving, we
can permit it in stable code if it derives from
deriving (not-even-a-pun intended)
|
|
Include source text in JSON errors
|
|
|
|
Now it is impossible for `...` or `a...` to reach HIR lowering
without a rogue syntax extension in play.
|
|
End-less ranges (`a...`) don't parse but bad syntax extensions could
conceivably produce them. Unbounded ranges (`...`) do parse and are
caught here.
The other panics in HIR lowering are all for unexpanded macros, which
cannot be constructed by bad syntax extensions.
|
|
|
|
|
|
add naked function tracking issue # to feature gate definition
|
|
|
|
convert 99.9% of `try!`s to `?`s
The first commit is an automated conversion using the [untry] tool and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[untry]: https://github.com/japaric/untry
cc @rust-lang/lang @alexcrichton @brson
|
|
|
|
|
|
|
|
Automated conversion using the untry tool [1] and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[1]: https://github.com/japaric/untry
|
|
Closes #31994
|
|
closes #31804
|
|
|
|
|
|
syntax: impl ToTokens for P<ast::ImplItem>
I'm working on updating zinc for latest rust, and it appears that I need this impl[0].
More generally, I realise that libsyntax is "Whatever the compiler team needs to build a compiler", but should I just open a PR fleshing this out for all types?
https://github.com/hackndev/zinc/blob/master/ioreg/src/builder/setter.rs#L194-L197
|
|
|
