[auto-toolstate] Upload the toolstate result to an external git repository, and removes BuildExpectation
This PR consists of 3 commits.
1. (Steps 4–6) The `toolstate.json` output previously collected is now pushed to the https://github.com/rust-lang-nursery/rust-toolstate repository.
2. (Step 7) Revert commit ab018c7, thus removing all traces of `BuildExpectation` and `toolstate.toml`.
3. (Step 8) Adjust CONTRIBUTION.md for the new procedure.
These are the last steps of #45861. After this PR, the toolstate will be automatically computed and published to https://rust-lang-nursery.github.io/rust-toolstate/. There is no need to manage toolstate.toml again.
Closes#45861.
This reverts commit ab018c76e14b87f3c9e0b7384cc9b02d94779cd5.
This also adds the `ToolBuild::is_ext_tool` field to replace the previous
`ToolBuild::expectation` field, to indicate whether a build-failure of
certain tool is essential.
Add support for CloudABI targets to the rustc backend.
CloudABI is a sandboxed UNIX-like runtime environment. It is a
programming environment that uses a capability-based security model. In
practice this means that many POSIX interfaces are present, except for
ones that try to access resources out of thin air. For example, open()
is gone, but openat() is present.
Right now I'm at the point where I can compile very basic CloudABI
applications on all four supported architectures (ARM and x86, 32 and 64
bits). The next step will be to get libstd to work. Patches for that are
outside the scope of this change.
More info: https://nuxi.nl/cloudabi/https://github.com/NuxiNL/cloudlibc/
Do not emit type errors on recovered blocks
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
Fix#44579.
Implement non-mod.rs mod statements
Fixes https://github.com/rust-lang/rust/issues/45385, cc https://github.com/rust-lang/rust/issues/44660
This will fail tidy right now because it doesn't recognize my UI tests as feature-gate tests. However, I'm not sure if compile-fail will work out either because compile-fail usually requires there to be error patterns in the top-level file, which isn't possible with this feature. What's the recommended way to handle this?
incr.comp.: Add `-C incremental` in addition to `-Z incremental`
This PR adds a stable commandline option for invoking incremental compilation.
r? @alexcrichton
trait alias infrastructure
This will be an implementation of trait aliases (RFC 1733, #41517).
Progress so far:
- [x] Feature gate
- [x] Add to parser
- [x] `where` clauses
- [x] prohibit LHS type parameter bounds via AST validation https://github.com/rust-lang/rust/pull/45047#discussion_r143575575
- [x] Add to AST and HIR
- [x] make a separate PathSource for trait alias contexts https://github.com/rust-lang/rust/pull/45047#discussion_r143353932
- [x] Stub out enough of typeck and resolve to just barely not ICE
Postponed:
- [ ] Actually implement the alias part
- [ ] #21903
- [ ] #24010
I need some pointers on where to start with that last one. The test currently does this:
```
error[E0283]: type annotations required: cannot resolve `_: CD`
--> src/test/run-pass/trait-alias.rs:34:16
|
34 | let both = foo();
| ^^^
|
= note: required by `foo`
```
Validate miri against the HIR const evaluator
r? @eddyb
cc @alexcrichton @arielb1 @RalfJung
The interesting parts are the last few functions in `librustc_const_eval/eval.rs`
* We warn if miri produces an error while HIR const eval does not.
* We warn if miri produces a value that does not match the value produced by HIR const eval
* if miri succeeds and HIR const eval fails, nothing is emitted, but we still return the HIR error
* if both error, nothing is emitted and the HIR const eval error is returned
So there are no actual changes, except that miri is forced to produce the same values as the old const eval.
* This does **not** touch the const evaluator in trans at all. That will come in a future PR.
* This does **not** cause any code to compile that didn't compile before. That will also come in the future
It would be great if someone could start a crater run if travis passes
Allow feature-gate tests to live in ui/ and migrate most of the tests from compile-fail
The PR consists of three commits:
1. change tidy to allow feature-gate tests to live in ui/
2. migrate some feature gate tests to ui/ with renaming only
3. migrate some feature gate tests to ui/ with also removing `// gate-test-...` lines and renaming them to the standard `feature-gate-<feat-name>.rs` format.
ui tests are the future, especially since the
recent improvement where we have gained
checking and requiring of //~ERROR comments.
The tidy feature-gate test check is intended
to be 50% an actual insurance that there is
a check, and 50% to be a teacher that such
checks are required.
With this commit applied, newbies might
interpret stuff wrongly and create tests
that don't fail but succeed instead.
This is not what feature gate tests are
for though. Therefore, in a later step,
when only ui tests are allowed to be feature
gate tests, we will add checking to ensure
that a file marked as gate test is actually
required to be a compilation failure.
Right now implementing such a check is a
bit annoying as one needs to only do it
when the compile-fail test is in the
ui test suite :/.
