ty: return impl Iterator from Predicate::walk_tys
Fixes the lazyboye `FIXME` by returning a custom `Iterator` as intended by the original author of the function.
It is indeed a bit convoluted, so I'm ok with not changing this if perf results are not favourable enough. Also happy to adjust any names if need be.
Previously this threshold when testing was 100ns, but the Windows
documentation states:
> which is a high resolution (<1us) time stamp
which presumably means that we could have up to 1us resolution, which
means that 100ns doesn't capture "equivalent" time intervals due to
various bits of rounding here and there.
It's hoped that this..
Closes#56034
reword #[test] attribute error on fn items
fix of [#55787](https://github.com/rust-lang/rust/issues/55787)
Reworded error message from "#[test] attribute is only allowed on fn items" to "#[test] attribute is only allowed on non associated functions"
core/tests/num: Simplify `test_int_from_str_overflow()` test code
This commit changes the test code to compare against easier-to-read, static values instead of relying on the result of `wrapping_add()` which may or may not result in the value that we expect.
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!
