Due to rust-lang/cargo#4570, a `*.dll.lib` file is uplifted when building
dynamic libraries on Windows. The current bootstrap code does not
understand files with multiple extensions, and will instead assume
`xxxx.dll` is the file name. This caused a `no output generated` error
because it tries to search for `xxxx.dll-hash.lib` inside the `deps/`
folder, while it should check for `xxxx-hash.dll.lib` instead.
This PR is blocking #45285 (Bump to 1.23 and update bootstrap).
Create NormalizeTy query
As part of the effort to solve #44891, I've created the normalize_ty query.
As outlined in the issue this meant:
- renamed `normalize_associated_type()` to `normalize_associated_type_in()`
- created the `normalize_ty` query
- substituted the use of memoize with the query
This PR is not ready. While running tests, one of the incremental ones failed. [This](https://pastebin.com/vGhH6bv6) is the error I got.
Move Generics from MethodSig to TraitItem and ImplItem
As part of `rust-impl-period/WG-compiler-traits`, we want to "lift" `Generics` from `MethodSig` into `TraitItem` and `ImplItem`. This is in preparation for adding associated type generics. (https://github.com/rust-lang/rust/issues/44265#issuecomment-331172238)
Currently this change is only made in the AST. In the future, it may also impact the HIR. (Still discussing)
To understand this PR, it's probably best to start from the changes to `ast.rs` and then work your way to the other files to understand the far reaching effects of this change.
r? @nikomatsakis
These functions were deprecated and removed in 1.5, but such simple
functionality shouldn't require using unsafe code, and it isn't
cluttering libstd too much.
Now that we are visiting things in a different order during lowering,
adding parameters winds up affecting the HirIds assigned to thinks in
the method body, whereas it didn't before. We could fix this by
reordering the order in which we visit `generics` during lowering, but
this feels very fragile. Seems better to just let typeck tables be
dirty here.
Fix rustbuild --color conflict when building on Travis outside of Docker
When trying to build rust on Travis without using `stamp` or `docker`, both `RUSTC_COLOR=1` and `TRAVIS=true` will separately pass `--color always` to the command line. This causes the build to fail due to "*Option 'color' given more than once*".
In this PR, the `RUSTC_COLOR=1` will not be passed in the CI environment.
rustbuild: Build stage 1 error index generator at stage 0
At stage 1 rustdoc is built at stage 0 so the error index generator should be as well.
This fixes `x.py --stage 1 doc` as rustdoc doesn't even build at stage 1.
It was broken by #44605.
r? @alexcrichton
update jobserver version to work around macos bug
Update `jobserver` crate to fixrust-lang/cargo#4643, a panic which can't happen according to `libc::poll`'s man page but was nevertheless reported on macOS 10.9 and 10.10.
r? @alexcrichton
rustbuild: Compile rustc with ThinLTO
This commit enables ThinLTO for the compiler as well as multiple codegen units.
This is intended to get the benefits of parallel codegen while also avoiding
any major loss of perf. Finally this commit is also intended as further testing
for #45320 and shaking out bugs.
