Clean up some non-mod-rs stuff.
This includes the following:
- Remove unused `non_modrs_mods` from `ParseSess` which as only used for feature gate diagnostics.
- Remove the vestiges of the feature gate tests in `test/ui`, they were only partially removed during stabilization.
- Fix the run-pass test, it was accidentally removed during stabilization.
- Add a ui test to verify error behavior for missing inline-nested mods.
- Add some tests for `#[path]` for inline-nested mods (both mod and non-mod-rs).
- Enable the diagnostic tests on windows, they should be fixed by #49478.
cc @cramertj
Stress test for MPSC
`concurrent_recv_timeout_and_upgrade` reproduces a problem 100%
times on my MacBook with command:
```
./x.py test --stage 0 ./src/test/run-pass/mpsc_stress.rs
```
Thus it is commented out.
Other tests cases were useful for catching another test cases
which may arise during the fix.
This diff is a part of my previous rewrite attempt: #42883
CC #39364
rustdoc: properly calculate spans for intra-doc link resolution errors
Fixes https://github.com/rust-lang/rust/issues/55723
When rustdoc is reporting a resolution error for intra-doc links, it needs to convert a span from one relative to the *markdown* (as the links are only found on the final markdown text) to one relative to the *source code* (as the error reporting is meant to show where the line is in the source, so the user can fix it). However, a calculation for how much "offset" to apply had a subtle error: it trimmed the whole line when attempting to account for leading indentation. This caused it to add in *trailing* whitespace into this calculation, which created an incorrect span.
In a lot of situations, this isn't a problem - the span will be shifted in the code slightly, but the warning will still be displayed and mostly legible. However, there is one important situation where this can cause an ICE: multi-byte codepoints. If a shifted span now has a starting point in the middle of a multi-byte codepoint, libsyntax will panic when trying to track what source item it corresponds to. This flew under our radar because trailing whitespace and multi-byte codepoints are both situations that we don't run into in the compiler repo.
(There is one more situation where this can error, that will be much harder to fix: block-style doc comments. Lines in a block-style doc comment have a zero-or-more (usually one) character offset per line, causing this calculation to be way off. I'm punting that to another issue, though...)
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.
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!
rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods
This PR is the continuation of #54012 and earlier PRs, in the grand plan of #45274 to allow for multiple codegen backends.
High-level summary: interpose a set of traits between Rust's codegen logic and the LLVM APIs, allowing another backend to implement the traits and share most of the codegen logic. These traits are currently somewhat LLVM-specific, but once this refactoring is in place, they can evolve to be more general.
See [this README](756f84d7ce/src/librustc_codegen_ssa/README.md) for a writeup on the current trait organization.
