Shorten names of some compiler generated artifacts.
This PR makes the compiler mangle codegen unit names by default. The name of every codegen unit name will now be a random string of 16 characters. It also makes the file extensions of some intermediate compiler products shorter. Hopefully, these changes will reduce the pressure on tools with path length restrictions like buildbot. The change should also solve problems with case-insensitive file system.
cc #47186 and #47222
r? @alexcrichton
Restore working debuginfo tests by trimming comments from non-header directive lines
I noticed when adding a debuginfo test that nothing I did caused the test to fail. Tracing back this seems to have been caused by 3e6c83de1d which broke parsing of the command/check lines, leaving all tests passing without any checking. This commit provides a basic (although still not very robust) restoration of tests and a should-fail test which checks the parser is running
First cut at getting some part of the test suite working for CloudABI
I am currently working on creating a Docker container for automated CI for CloudABI. Here are some of the trivial changes that need to land to make tests pass.
Tiny fixes to make compiletest work for CloudABI cross builds
I'm currently working toward getting a `src/ci/docker` container working to do isolated/automated builds and testing of `x86_64-unknown-cloudabi`. This is working pretty well, but still requires some fixes to `libtest` and `compiletest`. Here is the first set of fixes that I had to apply.
This structure doesn't seem to be used by libtest itself. It is used by
compiletest, but never passed on to anything externally. This makes it
easier to get the testing framework to work for CloudABI crossbuilds, as
CloudABI currently lacks PathBuf, which is used by TestPaths.
Update `rand` crate to `0.3.19`.
Update `log` crate to `0.3.9` and `0.4.1`.
Update `parking_lot_core` crate to `0.2.9`.
Upgrade all flate2 dependencies to `1.0.1`.
- Update `rust-installer` submodule.
Add a tidy check for missing or too many trailing newlines.
I've noticed recently there are lots of review comments requesting to fix trailing newlines. If this is going to be an official style here, it's better to let the CI do this repetitive check.
[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 ab018c76e1.
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/
Background
==========
Slices currently have an unstable [`rotate`] method which rotates
elements in the slice to the _left_ N positions. [Here][tracking] is the
tracking issue for this unstable feature.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
Proposal
========
Deprecate the [`rotate`] method and introduce `rotate_left` and
`rotate_right` methods.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_left(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_right(2);
assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']);
```
Justification
=============
I used this method today for my first time and (probably because I’m a
naive westerner who reads LTR) was surprised when the docs mentioned that
elements get rotated in a left-ward direction. I was in a situation
where I needed to shift elements in a right-ward direction and had to
context switch from the main problem I was working on and think how much
to rotate left in order to accomplish the right-ward rotation I needed.
Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts
right-ward. Both of their implementations allow passing negative numbers
to shift in the opposite direction respectively.
Introducing `rotate_left` and `rotate_right` would:
- remove ambiguity about direction (alleviating need to read docs 😉)
- make it easier for people who need to rotate right
[`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate
[tracking]: https://github.com/rust-lang/rust/issues/41891
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`
```
