in which the E0618 "expected function" diagnostic gets a makeover
A woman of wisdom once told me, "Better late than never." (Can't reopen the previously-closed pull request from six months ago [due to GitHub limitations](https://github.com/rust-lang/rust/pull/51098#issuecomment-437647157).)
Now the main span focuses on the erroneous not-a-function callee, while showing the entire call expression is relegated to a secondary span. In the case where the erroneous callee is itself a call, we
point out the definition, and, if the call expression spans multiple lines, tentatively suggest a semicolon (because we suspect that the "outer" call is actually supposed to be a tuple).
The new `bug!` assertion is, in fact, safe (`confirm_builtin_call` is only called by `check_call`, which is only called with a first arg of kind `ExprKind::Call` in `check_expr_kind`).
Resolves#51055.
r? @estebank
Forward the ABI of the non-zero sized fields of an union if they have the same ABI
This is supposed to fix the performence regression of using MaybeUninit in
https://github.com/rust-lang/rust/pull/54668
A few tweaks to iterations/collecting
- simplify and speed up `dot::GraphWalk::nodes` for `cfg::CFG`
- `reserve` the capacity for `edges` in `DepGraph::query`
- collect directly to a `HirVec` in `LoweringContext::lower_attrs`
- fix overallocation in `OnDiskCache::serialize`
- preallocate the `new_partitioning` vector in `merge_codegen_units`
- simplify `impl FromHex for str`
- improve the creation of `self_arg_names` in `impl MethodDef`
test/linkage-visibility: Ignore on musl targets
DynamicLibrary uses libc's dlsym() function internally to find symbols.
Some implementations of dlsym(), like musl's, only look at dynamically-
exported symbols, as found in shared libraries. To also export symbols
from the main executable, pass --export-dynamic to the linker.
(Plus see [here](https://stackoverflow.com/questions/4184017) and [here](https://stackoverflow.com/questions/6121838) for examples of where this is necessary on glibc as well.)
Add powerpc- and powerpc64-unknown-linux-musl targets
Add targets for musl on 32-bit and 64-bit powerpc. This requires some ABI fixes, as musl [uses the ELFv2 ABI on regardless of endianness](http://git.musl-libc.org/cgit/musl/tree/configure?id=8084d6ab57cdb0b8f328d3cdbad3b9d09eaaee04#n638). At the moment, powerpc64 support requires [an LLVM patch](https://reviews.llvm.org/D52013) to select the correct ABI; or I can add [a patch to Rust's LLVM backend](e8eaa2afd5) to always choose the right ABI.
Both architectures are able to run an extended bootstrap, and with some test fixes (e.g. #55561), there are no architecture-dependent test failures on powerpc64 (most failures in `src/test` are existing musl-host-related issues).
std: Add debugging for a failing test on appveyor
I'm not sure why this is failing, so let's hopefully get some more
information to help investigation!
