Fix Unreadable non-UTF-8 output on localized MSVC
Fixes#35785 by converting non UTF-8 linker output to Unicode using the OEM code page.
Before:
```text
= note: Non-UTF-8 output: LINK : fatal error LNK1181: cannot open input file \'m\x84rchenhaft.obj\'\r\n
```
After:
```text
= note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj'
```
The difference is more dramatic if using a non-ascii language pack for Windows.
Fixes https://github.com/rust-lang/rust/issues/110912
Checking `flavor == RlibFlavor::Normal` was accidentally lost in
601fc8b36bhttps://github.com/rust-lang/rust/pull/105601
That caused combining +whole-archive and +bundle link modifiers on
non-rlib crates to fail with a confusing error message saying that
combination is unstable for rlibs. In particular, this caused the
build to fail when +whole-archive was used on staticlib crates, even
though +whole-archive effectively does nothing on non-bin crates because
the final linker invocation is left to an external build system.
Fixes#35785 by converting non UTF-8 linker output to Unicode using the OEM code page.
Before:
```text
= note: Non-UTF-8 output: LINK : fatal error LNK1181: cannot open input file \'m\x84rchenhaft.obj\'\r\n
```
After:
```text
= note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj'
```
The difference is more dramatic if using a non-ascii language pack for Visual Studio.
The name of NativeLib will be presented
Fixes#109144
I was working on a quick fix, but found change the name from `Option<Symbol>` to `Symbol` make life a little bit easier.
Append .dwp to the binary filename instead of replacing the existing extension.
gdb et al. expect to find the dwp file at `<binary>`.dwp, even if <binary> already has an extension (e.g. libfoo.so's dwp is expected to be at libfoo.so.dwp).
gdb et al. expect to find the dwp file at <binary>.dwp, even if <binary> already
has an extension (e.g. libfoo.so's dwp is expected to be at libfoo.so.dwp).
The optimization that removes artifacts when building libraries is correct
from the compiler's perspective but not from a debugger's perspective.
Unpacked split debuginfo is referred to by filename and debuggers need
the artifact that contains debuginfo to continue to exist at that path.
Ironically the test expects the correct behavior but it was not running.
Linker drivers such as gcc, clang or lld often have a version postfix,
e.g clang-12. The previous logic would not account for this and would
fall back to guessing the linker flavor to be the default linker flavor
for the target, which causes linker errors when this is not the case.
By accounting for the possible version postfix and also considering
g++ and clang++, we considerably reduce the amount of times the
fallback guess has to be used.
To simplify matching check for a version postfix and match against the
linker stem without any version postfix.
In contrast to gcc, clang supports all architectures in one binary.
This means there are no variants like `aarch64-linux-gnu-clang` and
there is no need to check for `-clang` variants.
Migrate `codegen_ssa` to diagnostics structs - [Part 3]
Completes migrating `codegen_ssa` module except 2 outstanding errors that depend on other crates:
1. [`rustc_middle::mir::interpret::InterpError`](b6097f2e1b/compiler/rustc_middle/src/mir/interpret/error.rs (L475)): I saw `rustc_middle` is unassigned, I am open to take this work.
2. `codegen_llvm`'s use of `fn span_invalid_monomorphization_error`, which I started to replace in the [last commit](9a31b3cdda) of this PR, but would like to know the team's preference on how we should keep replacing the other macros:
2.1. Update macros to expect a `Diagnostic`
2.2. Remove macros and expand the code on each use.
See [some examples of the different options in this experimental commit](64aee83e80)
_Part 2 - https://github.com/rust-lang/rust/pull/103792_
r? ``@davidtwco``
Cc ``@compiler-errors``
Small fixes for --crate-type staticlib
The first commit doesn't have an effect until we start translating error messages. The second commit fixes potential linker errors when combining `--crate-type staticlib` with another crate type and I think `-Cprefer-dynamic`.
On macOS, it's not yet clear which cases of clang/OS/target/SDK version impact
how to find ld/lld/rust-lld. The --target is not needed on our current targets with
a vanilla config, but may be in some cases. Specifying it all the time breaks the 10.7+
targets on x64 macOS.
We try to only specify it on macOS if the linker flavors are different,
for possible cases of cross-compilation with `-Zgcc-ld=lld` but the
expectation is that it should be passed manually when needed in these
situations.
Wrap bundled static libraries into object files
Fixes#103044 (not sure, couldn't test locally)
Bundled static libraries should be wrapped into object files as it's done for metadata file.
r? `@petrochenkov`
improve `filesearch::get_or_default_sysroot`
`fn get_or_default_sysroot` is now improved and used in `miri` and `clippy`, and tests are still passing as they should. So we no longer need to implement custom workarounds/hacks to find sysroot in tools like miri/clippy.
Resolves https://github.com/rust-lang/rust/issues/98832
re-opened from #103581
FIX - StrippingDebugInfoFailed typo
DELETE - unneeded FIXME comment
UPDATE - only declare the error with ExtractBundledLibsError as an enum and use the Diagnostic derive macro
