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.
Previously, a Step would be able to tell on its own when it was invoked
"by-default" (that is, `./x.py test` was called instead of `./x.py test
some/path`). This commit replaces that functionality, invoking each Step
with each of the paths it has specified as "should be invoked by."
For example, if a step calls `path("src/tools/cargo")` and
`path("src/doc/cargo")` then it's make_run will be called twice, with
"src/tools/cargo" and "src/doc/cargo." This makes it so that default
handling logic is in builder, instead of spread across various Steps.
However, this meant that some Step specifications needed to be updated,
since for example `rustdoc` can be built by `./x.py build
src/librustdoc` or `./x.py build src/tools/rustdoc`. A `PathSet`
abstraction is added that handles this: now, each Step can not only list
`path(...)` but also `paths(&[a, b, ...])` which will make it so that we
don't invoke it with each of the individual paths, instead invoking it
with the first path in the list (though this shouldn't be depended on).
Future work likely consists of implementing a better/easier way for a
given Step to work with "any" crate in-tree, especially those that want
to run tests, build, or check crates in the std, test, or rustc crate
trees. Currently this is rather painful to do as most of the logic is
duplicated across should_run and make_run. It seems likely this can be
abstracted away into builder somehow.
Fix oversized loads on x86_64 SysV FFI calls
The x86_64 SysV ABI should use exact sizes for small structs passed in
registers, i.e. a struct that occupies 3 bytes should use an i24,
instead of the i32 it currently uses.
Refs #45543
Emit data::Impl in save-analysis
As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis.
A number of questions are outstanding:
- [x] A few `???` around row 356. We need to discuss what goes here, if anything.
- [ ] ~~Deriving `id` for impl using hashing. Is this going to clash with rustc defids?~~
- [ ] ~~Deriving `id` for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?~~
- [x] Need a new rls-data with an `id` field in `Impl` struct.
- [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~
rustc_mir: insert a dummy access to places being matched on, when building MIR.
Fixes#47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`.
r? @nikomatsakis
Document the behaviour of infinite iterators on potentially-computable methods
It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
Explain unusual debugging code in librustc
Introduced in #47828 to help track down some bugs, it landed a bit hastily so
this is intended on cleaning it up a bit.
Update the dlmalloc submodule
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
Add fetch_nand to atomics
I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...
cc #13226 (the tracking issue)
ci: Actually bootstrap on i686 dist
Right now the `--build` option was accidentally omitted, so we're bootstraping
from `x86_64` to `i686`. In addition to being slower (more compiles) that's not
actually bootstrapping!
Disallow function pointers to #[rustc_args_required_const]
This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.
Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!
rustbuild: Pass `ccache` to build scripts
Right now the ccache setting is only used for LLVM, but this tweaks it to also
be used for build scripts so C++ builds like `librustc_llvm` can be a bit
speedier.
Fix ICE for mismatched args on target without span
Commit 7ed00caacc improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from #48046 is assigning `str::split` to a function type with a different number of arguments.
Fix by omitting all of the labels and suggestions related to the target span when it's not found.
Fixes#48046
r? @estebank
Customizable extended tools
This PR adds `build.tools` option to manage installation of extended rust tools.
By default it doesn't change installation. All tools are built and `rls` and `rustfmt` allowed to fail installation.
If some set of tools chosen only those tools are built and installed without any fails allowed.
It solves some slotting issues with extended build enabled: https://bugs.gentoo.org/show_bug.cgi?id=645498
Create a directory for --out-dir if it does not already exist
Currently if `--out-dir` is set to a non-existent directory, the compiler will throw unfriendly messages like `error: could not write output to subdir/example.crate.allocator.rcgu.o: No such file or
directory`, which, while not completely unreadable, isn’t very user-friendly either. This change creates the directory automatically if it does not yet exist.
rustc: Upgrade to LLVM 6
The following submodules have been updated for a new version of LLVM:
- `src/llvm`
- `src/libcompiler_builtins` - transitively contains compiler-rt
- `src/dlmalloc`
This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.
The [current set of custom rustc-specific patches](f1286127b7...rust-llvm-release-6-0-0) included in this LLVM update are:
* rust-lang/llvm@1187443 - this is how we actually implement
`cfg(target_feature)` for now and continues to not be upstreamed. While a
hazard for SIMD stabilization this commit is otherwise keeping the status
quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
upstreamed, notably teaching LLVM about our allocation-related routines (which
aren't malloc/free). Once we stabilize the global allocator routines we will
likely want to upstream this patch, but for now it seems reasonable to keep it
on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
our 32-bit linux container. I'm not really sure why it's necessary but my
guess is that it's because of the absolutely ancient glibc that we're using.
In any case it's only updating pieces we're not actually using in LLVM so I'm
hoping it'll turn out alright. This doesn't seem like something we'll want to
upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
i686-freebsd container, I'm not really sure what's going on but we for sure
probably don't want to upstream this and otherwise it seems not too bad for
now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
which although diagnosed to a particular revision isn't currently fixed
upstream (and the bug itself doesn't seem too active). This commit is a
partial revert of the suspected cause of this regression (found via a
bisection). I'm sort of hoping that this eventually gets fixed upstream with a
similar fix (which we can replace in our branch), but for now I'm also hoping
it's a relatively harmless change to have.
After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!
In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@2717444), [another change to pass manager
order](rust-lang/llvm@c782feb), some [compile fixes for
sparc](rust-lang/llvm@1a83de6), and some [fixes for
solaris](rust-lang/llvm@c2bfe0a).
[patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1
[backport]: rust-lang/llvm@5c54c25
[llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114
[upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096
---
The update to LLVM 6 is desirable for a number of reasons, notably:
* This'll allow us to keep up with the upstream wasm backend, picking up new
features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!
This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!
Closes#43370Closes#43418Closes#47015Closes#47683Closesrust-lang-nursery/stdsimd#157Closesrust-lang-nursery/rust-wasm#3
