Cleanup codegen_llvm/back
- improve allocations
- use `Cow<'static, str>` where applicable
- use `to_owned` instead of `to_string` with string literals
- remove a redundant `continue`
- possible minor speedup in logic
- use `mem::replace` instead of `swap` where more concise
- remove `'static` from consts
- improve common patterns
- remove explicit `return`s
- whitespace & formatting fixes
Implement rotate using funnel shift on LLVM >= 7
Implement the rotate_left and rotate_right operations using
llvm.fshl and llvm.fshr if they are available (LLVM >= 7).
Originally I wanted to expose the funnel_shift_left and
funnel_shift_right intrinsics and implement rotate_left and
rotate_right on top of them. However, emulation of funnel
shifts requires emitting a conditional to check for zero shift
amount, which is not necessary for rotates. I was uncomfortable
doing that here, as I don't want to rely on LLVM to optimize
away that conditional (and for variable rotates, I'm not sure it
can). We should revisit that question when we raise our minimum
version requirement to LLVM 7 and don't need emulation code
anymore.
Fixes#52457.
Do not attempt to ascribe projections out of a ty var
If we encounter `_` ascribed to structural pattern like `(a, b)`, just skip relate_types.
Fix#55552
Bubble up an overflow error so that rustdoc can ignore it
fixes#54524
Idk how to write a test for this, other than trying to minimize the entire diesel crate. If desirable I will do that.
Note that there are many other such overflow errors hiding out there. Should we try to proactively eliminate them or do we just whack-a-mole them?
cc @GuillaumeGomez
r? @nikomatsakis
Update emscripten
This updates emscripten to 1.38.15, which is based on LLVM 6.0.1 and would allow us to drop code for handling LLVM 4.
The main issue I ran into is that exporting statics through `EXPORTED_FUNCTIONS` no longer works. As far as I understand exporting non-functions doesn't really make sense under emscripten anyway, so I've modified the symbol export code to not even try.
Closes#52323.
Rollup of 17 pull requests
Successful merges:
- #55576 (Clarify error message for -C opt-level)
- #55633 (Support memcpy/memmove with differing src/dst alignment)
- #55638 (Fix ICE in msg_span_from_free_region on ReEmpty)
- #55659 (rustc: Delete grouping logic from the musl target)
- #55719 (Sidestep link error from rustfix'ed code by using a *defined* static.)
- #55736 (Elide anon lifetimes in conflicting impl note)
- #55739 (Consume optimization fuel from the MIR inliner)
- #55742 (Avoid panic when matching function call)
- #55753 (borrow_set: remove a helper function and a clone it uses)
- #55755 (Improve creation of 3 IndexVecs)
- #55758 ([regression - rust2018]: unused_mut lint false positives on nightly)
- #55760 (Remove intermediate font specs)
- #55761 (mir: remove a hacky recursive helper function)
- #55774 (wasm32-unknown-emscripten expects the rust_eh_personality symbol)
- #55777 (Use `Lit` rather than `P<Lit>` in `ast::ExprKind`.)
- #55783 (Deprecate mpsc channel selection)
- #55788 (rustc: Request ansi colors if stderr isn't a tty)
Failed merges:
r? @ghost
rustc: Request ansi colors if stderr isn't a tty
Currently Cargo will always capture the output of rustc meaning that
rustc is never hooked up to a tty. To retain colors Cargo uses the
`fwdansi` crate to ensure that ansi color codes are translated to
windows terminal methods (and ansi codes otherwise just go their natural
route on Unix).
Cargo passes `--color always` to rustc to ensure that using a pipe
doesn't trick it into not emitting colors at all. It turns out, however,
that `--color always` ends up still accidentally using the native shell
api on native windows shells.
The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of
`Always`, ensuring that when `--color always` is passed to rustc and its
output isn't a terminal, we're always generating ansi colors regardless
of the platform.
Closes#55769
wasm32-unknown-emscripten expects the rust_eh_personality symbol
The `wasm32-unknown-emscripten` expects the `rust_eh_personality` symbol to be there, but a cfg checking for `target_arch = "wasm32"` which was meant to remove the symbol from the `wasm32-unknown-unknown` target, didn't check for whether `emscripten` is targeted or not, so the symbol accidentally got filtered out there as well.
Fixes#55276
Remove intermediate font specs
This is a (much) more constrained version of #54772 that also aims at improving the situation in #34681. It removes any font specifications that are not the "official" rustdoc font, and instead relies on the browser to provide the fallback font if the official on is not available. On Linux systems, this is particularly important, as fonts like Helvetica, Arial, and Times often look pretty bad since they're pulled from extracted MS fonts. A specification like `serif` or `sans-serif` lets the browser instead choose a good font.
[regression - rust2018]: unused_mut lint false positives on nightly
Fixes#55344.
This commit filters out locals that have never been initialized for
consideration in the `unused_mut` lint.
This is intended to detect when the statement that would have
initialized the local was removed as unreachable code. In these cases,
we would not want to lint. This is the same behaviour as the AST borrow
checker.
This is achieved by taking advantage of an existing pass over the MIR
for the `unused_mut` lint and creating a set of those locals that were
never initialized.
r? @pnkfelix
Avoid panic when matching function call
Fix#55718
This bug is introduced by #53751. The original code checked `Def::AssociatedConst(..) | Def::Method(..)` before `pat_ty.no_bound_vars().expect("expected fn type")`. But somehow I exchanged the sequence carelessly. Sorry about that.
r? @petrochenkov
Consume optimization fuel from the MIR inliner
This makes it easier to debug mis-optimizations that occur during
inlining. Thanks to @nikomatsakis for the suggestion!
Sidestep link error from rustfix'ed code by using a *defined* static.
As a drive-by, added `-g` to the compile-flags so that the test more
reliably fails to compile when the extern static in question is *not*
provided. (I.e. this is making the test more robust in the face of
potential future revisions.)
Fix#54388.
rustc: Delete grouping logic from the musl target
This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:
$ echo 'fn main() {}' >> foo.rs
$ rustc --target x86_64-unknown-linux-musl -C panic=abort
you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).
The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
Support memcpy/memmove with differing src/dst alignment
If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version.
Fixes#49740.
Currently Cargo will always capture the output of rustc meaning that
rustc is never hooked up to a tty. To retain colors Cargo uses the
`fwdansi` crate to ensure that ansi color codes are translated to
windows terminal methods (and ansi codes otherwise just go their natural
route on Unix).
Cargo passes `--color always` to rustc to ensure that using a pipe
doesn't trick it into not emitting colors at all. It turns out, however,
that `--color always` ends up still accidentally using the native shell
api on native windows shells.
The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of
`Always`, ensuring that when `--color always` is passed to rustc and its
output isn't a terminal, we're always generating ansi colors regardless
of the platform.
Closes#55769
The `wasm32-unknown-emscripten` expects the `rust_eh_personality` symbol to be there, but a cfg checking for `target_arch = "wasm32"` which was meant to remove the symbol from the `wasm32-unknown-unknown` target, didn't check for whether `emscripten` is targeted or not, so the symbol accidentally got filtered out there as well.
Fixes#55276
Rollup of 14 pull requests
Successful merges:
- #55377 (Slight copy-editing for `std::cell::Cell` docs)
- #55441 (Remove unused re import in gdb_rust_pretty_printing)
- #55453 (Choose predicates without inference variables over those with them)
- #55495 (Don't print opt fuel messages to stdout because it breaks Rustbuild)
- #55501 (Make `process_obligations`' computation of `completed` optional.)
- #55510 (Fix feature gate only being checked on first repr attr.)
- #55609 (Run name-anon-globals after LTO passes as well)
- #55645 (do not print wrapping ranges like normal ranges in validity diagnostics)
- #55688 (Standardised names and location of ui issue tests)
- #55692 (-C remark: fix incorrect warning about requiring "--debuginfo" instead of "-C debuginfo=n")
- #55702 (Add `aarch64-pc-windows-msvc` to deployed targets)
- #55728 (Update lldb)
- #55730 (Use trait impl method span when type param mismatch is due to impl Trait)
- #55734 (refactor: use shorthand fields)
