ci: Print out how long each step takes on CI
This commit updates CI configuration to inform rustbuild that it should print
out how long each step takes on CI. This'll hopefully allow us to track the
duration of steps over time and follow regressions a bit more closesly (as well
as have closer analysis of differences between two builds).
cc #48829
Detect illegal hidden lifetimes in `impl Trait`
This branch fixes#46541 -- however, it presently doesn't build because it also *breaks* a number of existing usages of impl Trait. I'm opening it as a WIP for now, just because we want to move on impl Trait, but I'll try to fix the problem in a bit.
~~(The problem is due to the fact that we apparently infer stricter lifetimes in closures that we need to; for example, if you capture a variable of type `&'a &'b u32`, we will put *precisely* those lifetimes into the closure, even if the closure would be happy with `&'a &'a u32`. This causes the present chance to affect things that are not invariant.)~~ fixed
r? @cramertj
Download the GCC artifacts from the HTTP server instead of FTP server.
Try to bring back the `dist-i686-linux` and `dist-x86_64-linux alt` builders which has mysteriously lost their cache 14 hours ago and stuck forever unable to download `mpfr-2.4.2.tar.bz2` since it keeps getting
```
==> PASV ... couldn't connect to 209.132.180.131 port 10058: Connection timed out
```
Unfortunately we don't have sufficient time to rebuild the cache *and*
distribute everything in `dist-x86_64-linux alt`, the debug assertions are
really slow.
We will re-enable them after the PR has been successfully merged, thus
successfully updating the cache (freeing up 40 minutes), giving us enough
time to build these tools.
We used to make the upvar types in the closure `==` but that was
stronger than we needed. Subtyping suffices, since we are copying the
upvar value into the closure field. This in turn allows us to infer
smaller lifetimes in captured values in some cases (like the example
here), avoiding errors.
Fix ordering of auto-generated trait bounds in rustdoc output
While the order of the where clauses was deterministic, the
ordering of bounds and lifetimes was not. This made the order flip-
flop randomly when new traits and impls were added to libstd.
This PR makes the ordering of bounds and lifetimes deterministic,
and re-enables the test that was causing the issue.
Fixes#49123
This commit updates CI configuration to inform rustbuild that it should print
out how long each step takes on CI. This'll hopefully allow us to track the
duration of steps over time and follow regressions a bit more closesly (as well
as have closer analysis of differences between two builds).
cc #48829
This should fix regressions in Cargo after swithing to clap:
* If an external subcommand name was close to built-in one, clap
errored (fixed by updating clap version)
* External subcomands didn't received their name as a first arg
While the order of the where clauses was deterministic, the
ordering of bounds and lifetimes was not. This made the order flip-
flop randomly when new traits and impls were added to libstd.
This PR makes the ordering of bounds and lifetimes deterministic,
and re-enables the test that was causing the issue.
Fixes#49123
config.toml.example: thinlto bootstrap was removed
It was removed in ff227c4a2d so remove the option that no longer works (we did not notice because it was commented out by default).
Add BufReader::buffer
This subsumes the need for an explicit is_empty function, and provides
access to the buffered data itself which has been requested from time to
time.
We could call this `buf` to match `fill_buf`, but I think I'd prefer `fill_buffer` anyways in hindsight.
rustbuild: Ship libsynchronization
Hot on the heels of #49044 comes similar issue with libsynchronization. Discovered while building clippy:
```
<skipped>
Compiling serde_derive v1.0.33
error: linking with `gcc` failed: exit code: 1
<skipped>
= note: ld: cannot find -lsynchronization
```
r? @nikomatsakis
Suggest removing `&`s
This implements the error message discussed in #47744.
We check whether removing each `&` yields a type that satisfies the requested obligation.
Also, it was created a new `NodeId` field in `ObligationCause` in order to iterate through the `&`s. The way it's implemented now, it iterates through the obligation snippet and counts the number of `&`.
r? @estebank
Implement Integer methods for Wrapping
Wrapping<T> now implements:
count_ones, count_zeros, leading_zeros,
trailing_zeros, rotate_left, rotate_right, swap_bytes, from_be,
from_le, to_be, to_le, and pow
where T is:
u8, u16, u32, u64, usize, i8, i16, i32, i64, or isize.
Docs were written for all these methods, as well as examples. The
examples mirror the ones on u8, u16, etc... for consistency.
Closes#32463
Improve documentation for Borrow
This is the first step in improving the documentation for all the reference conversion traits. It proposes new text for the trait documentation of `Borrow`. Since I feel it is a somewhat radical rewrite and includes a stricter contract for `Borrow` then the previous text—namely that *all* shared traits need to behave the same, not just a select few—, I wanted to get some feedback before continuing.
Apart from the ‘normative’ description, the new text also includes a fairly extensive explanation of how the trait is used in the examples section. I included it because every time I look at how `HashMap` uses the trait, I need to think for a while as the use is a bit twisted. So, I thought having this thinking written down as part of the trait itself might be useful. One could argue that this should go into The Book, and, while I really like having everything important in the docs, I can see the text moved there, too.
So, before I move on: is this new text any good? Do we feel it is correct, useful, comprehensive, and understandable?
(This PR is in response to #44868 and #24140.)
