When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!
Hopefully addresses [this] spurious failure
[this]: https://github.com/rust-lang/rust/pull/48295#issuecomment-372134717
Update env_logger to 0.5.4
It looks like this cuts down on the number of dependencies in env_logger and
notably cuts out a difference between a shared dependency of rls/cargo. My goal
here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo
once, and this is one step towards that!
It looks like this cuts down on the number of dependencies in env_logger and
notably cuts out a difference between a shared dependency of rls/cargo. My goal
here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo
once, and this is one step towards that!
Handle gdb command failure gracefully in compiletest
Previously, if the gdb command was available, but threw an error, compiletest would panic. This is obviously not good. Now, gdb is treated as missing if calling `gdb --version` does not output anything on stdout.
Previously, if the gdb command was available, but threw an error, compiletest would panic. This is obviously not good. Now, gdb is treated as missing if calling `gdb --version` does not output anything on stdout.
1. When the invalid condition is hit, write out the relevant variables too
2. In compile-fail/parse-fail tests, check for ICE first, so the invalid
error patterns won't mask our ICE output.
This was originally copied over from Cargo and Cargo has since [been
updated][update] so let's pull in the fixes here too!
[update]: https://github.com/rust-lang/cargo/pull/5030
This isn't a perfect heuristic, but since the amount of run-fail tests
is far lower than run-pass tests for now, it should be sufficient to
ensure that we don't run into CI limits. This makes it possible to run
the test binary manually (e.g., under gdb/lldb) if it failed to attempt
to find out why.
ui tests: diff from old (expected) to new (actual) instead of backwards.
Previously `actual` was "old" and `expected` was "new" which resulted in `+` before `-`.
AFAIK all diff tools put `-` before `+`, which made the previous behavior *very confusing*.
r? @nikomatsakis
Add line numbers and columns to error messages spanning multiple files
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
rustc: Load the `rustc_trans` crate at runtime
Building on the work of #45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement #46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
Building on the work of # 45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement # 46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
libtest: Json format now outputs failed tests' stdouts.
libtest: Json format now outputs failed tests' stdouts.
libtest: Json formatter now spews individiual events, not as an array
libtest: JSON fixes
libtest: Better JSON escaping
libtest: Test start event is printed on time
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
-Z unpretty no longer requires -Z unstable-options. Also, I mildly
changed the syntax of the flag to match the other -Z flags. All uses of
the flag take the form `unpretty=something` where something can either
`string` or `string=string` (see the help messages of the CLI).
The function parse_cfg_prefix() is not really parsing. It's just checking
whether the prefix is present or not. So the new function name as suggested by
@Mark-Simulacrum is better.
Previous patch introduced something like if x {true} else {false} which can be
simply replaced by returning x here.
Thanks to @kennytm for spotting it.
This patch implements "only-<platforms>" for tests headers using which one can
specify just the platforms on which the test should run rather than listing all
the platforms to ignore using "ignore-<platforms>".
This is a fix for issues #33581 and #47459.
Show only stderr diff when a ui test fails
Addresses #46826.
This PR will print the normalized output if expected text is empty otherwise it will just print the diff.
Should we also show a few (actual == expected) lines above & below when displaying the diff? What about indicating line numbers as well so one can quickly check mismatch lines in .stderr file?
Deprecate [T]::rotate in favor of [T]::rotate_{left,right}.
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. The current `rotate`
implementation takes an unsigned integer argument which doesn't allow
the negative number behavior.
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
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
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.
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
