MSVC: Avoid using jmp stubs for dll function imports
Windows import libraries contain two symbols for every function: `__imp_FunctionName` and `FunctionName` (where `FunctionName` is the name of the function to be imported).
`__imp_FunctionName` contains the address of the imported function. This will be filled in by the Windows executable loader at runtime. `FunctionName` contains a jmp stub that simply jumps to the address given by `__imp_FunctionName`. E.g. it's a function that solely contains a single jmp instruction:
```asm
jmp __imp_FunctionName
```
When using an external DLL function in Rust, by default the linker will link to FunctionName, causing a bit of indirection at runtime. In Microsoft's C++ it's possible to instead tell it to insert calls to the address in `__imp_FunctionName` by using the `__declspec(dllimport)` attribute. In Rust it's possible to get effectively the same behaviour using the `#[link]` attribute on `extern` blocks.
----
The second commit also merges multiple `extern` blocks into one block. This is because otherwise Rust will currently create duplicate linker arguments for each block. In this case having duplicates shouldn't matter much other than the noise when displaying the linker command.
Move llvm submodule updates to rustbuild
This enables better caching, since LLVM is only updated when needed, not
whenever x.py is run. Before, bootstrap.py had to use heuristics to
guess if LLVM would be needed, and updated the module more often than
necessary as a result.
This syncs the LLVM submodule only just before building the compiler, so
people working on the standard library never have to worry about it.
Example output:
```
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Updating submodule src/llvm-project
Submodule 'src/llvm-project' (https://github.com/rust-lang/llvm-project.git) registered for path 'src/llvm-project'
Submodule path 'src/llvm-project': checked out 'f9a8d70b6e0365ac2172ca6b7f1de0341297458d'
```
Implements https://github.com/rust-lang/rust/issues/76653#issuecomment-770265169. This could be easily extended to other submodules, like `rust-by-example` and `rustc-dev-guide`, which aren't needed for cargo's workspace resolution.
This enables better caching, since LLVM is only updated when needed, not
whenever x.py is run. Before, bootstrap.py had to use heuristics to
guess if LLVM would be needed, and updated the module more often than
necessary as a result.
This syncs the LLVM submodule only just before building the compiler, so
people working on the standard library never have to worry about it.
Example output:
```
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Updating submodule src/llvm-project
Submodule 'src/llvm-project' (https://github.com/rust-lang/llvm-project.git) registered for path 'src/llvm-project'
Submodule path 'src/llvm-project': checked out 'f9a8d70b6e0365ac2172ca6b7f1de0341297458d'
```
- Don't try to update the LLVM submodule when using system LLVM
Previously, this would try to update LLVM unconditionally. Now the
submodule is only initialized if `llvm-config` is not set.
- Don't update LLVM submodule in dry runs
This prevents the following test failures:
```
running 17 tests
fatal: invalid gitfile format: /checkout/src/llvm-project/.git
test builder::tests::defaults::build_cross_compile ... FAILED
---- builder::tests::defaults::build_default stdout ----
thread 'main' panicked at 'command did not execute successfully: "git" "rev-parse" "HEAD"
expected success, got: exit code: 128', src/build_helper/lib.rs:139:9
```
- Try running git without --progress if it fails the first time
This avoids having to do version detection to see if --progress is
supported or not.
- Don't try to update submodules when the source repository isn't managed by git
- Update LLVM submodules that have already been checked out
- Only check for whether the submodule should be updated in lib.rs; update
it unconditionally in native.rs
CTFE get_alloc_extra_mut: also provide ref to MemoryExtra
This would let me use mutable references in more places in Stacked Borrows, avoiding some `RefCell` overhead. :)
r? `@oli-obk`
This sets their toggles to be closed in the HTML (matching the default
setting), and opens them if the setting indicates to do so.
This distinguishes between implementations and implementors based on
being descendants of certain named elements.
Swap TargetOptions::linker_is_gnu default from false to true and update targets as appropriate.
#85274 gated the `--gc-sections` flag on targets that specified `linker_is_gnu` to stop us from passing it to incompatible linkers. But that had the unintended effect of the flag no longer being passed on targets for which it is valid and hence caused a regression in binary size. Given that most `ld`-style linkers are GNU compatible, this change flips our default for `linker_is_gnu` from false to true. That also means updating the targets that relied on the previous default:
* Apple
* Illumos
* L4Re (not sure about this one)
* MSVC
* NvtPtx
* Solaris
Fixes#85519
Rollup of 4 pull requests
Successful merges:
- #85506 (Reset "focusedByTab" field when doing another search)
- #85548 (Remove dead toggle JS code)
- #85550 (facepalm: operator precedence fail on my part.)
- #85555 (Check for more things in THIR unsafeck)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
facepalm: operator precedence fail on my part.
This bug was only visible on mac. Also, print_step_rusage is a relatively new
internal feature, that is not heavily used, and has no tests. All of these
factors contributed to how this went uncaught this long. Thanks to Josh Triplett
for pointing it out!
Remove dead toggle JS code
Explanations on how I got there: I randomly saw `adjustToggle` while browsing through code, checked where it was called, put a `debugger;` instruction in it and checked on all pages while playing with settings and toggles. The breakpoint was never triggered. I then looked at `collapseNonInherent` (its grand-parent). In there, the breakpoint was triggered so I look at what was being done and in fact... nothing. So I simply removed it all, re-ran the tests and play with the UI. Everything is working as expected.
Better double check in case I forgot to check a case though, but if nothing has been left out, then it's a great cleanup once again. :)
r? ``@jsha``
Reset "focusedByTab" field when doing another search
Fixes https://github.com/rust-lang/rust/issues/85467.
The problem was simply that we forget to reset the `focusedByTab` field, which was still referring to removed DOM elements.
r? ``@jsha``
Adjust self-type check to require equality
When we encounter `SomeType::<X>::foo`, `self_ty` is `SomeType<X>` and the method is defined in an impl on `SomeType<A>`. Previously, we required simply that `self_ty <: impl_ty`, but this is too lax: we should require equality in order to use the method. This was found as part of unrelated work on never type stabilization, but also fixes one of the wf test cases.
This bug was only visible on mac. Also, print_step_rusage is a relatively new
internal feature, that is not heavily used, and has no tests. All of these
factors contributed to how this went uncaught this long. Thanks to Josh Triplett
for pointing it out!
PassWrapper: update for LLVM change D102093
In https://reviews.llvm.org/D102093 lots of things stopped taking the
DebugLogging boolean parameter. Mercifully we appear to always set
DebugPassManager to false, so I don't think we're losing anything by not
passing this parameter.
Windows implementation of feature `path_try_exists`
Draft of a Windows implementation of `try_exists` (#83186).
The first commit reorganizes the code so I would be interested to get some feedback on if this is a good idea or not. It moves the `Path::try_exists` function to `fs::exists`. leaving the former as a wrapper for the latter. This makes it easier to provide platform specific implementations and matches the `fs::metadata` function.
The other commit implements a Windows specific variant of `exists`. I'm still figuring out my approach so this is very much a first draft. Eventually this will need some more eyes from knowledgable Windows people.
