-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #108935
Rollup of 7 pull requests #108935
Conversation
The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order: - Template strings - Positional operands - Named operands - Explicit register operands - `clobber_abi` - `options` This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows: - Template strings must still come before all other operands. - Positional operands must still come before named and explicit register operands. - Named and explicit register operands can be freely mixed. - `options` and `clobber_abi` can appear in any position.
…r`s at the same time
Relax ordering rules for `asm!` operands The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order: - Template strings - Positional operands - Named operands - Explicit register operands - `clobber_abi` - `options` This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows: - Template strings must still come before all other operands. - Positional operands must still come before named and explicit register operands. - Named and explicit register operands can be freely mixed. - `options` and `clobber_abi` can appear in any position after the template strings. r? ```@joshtriplett```
…, r=pietroalbini use problem matchers for tidy CI
…king, r=pnkfelix Support linking to rust dylib with --crate-type staticlib This allows for example dynamically linking libstd, while statically linking the user crate into an executable or C dynamic library. For this two unstable flags (`-Z staticlib-allow-rdylib-deps` and `-Z staticlib-prefer-dynamic`) are introduced. Without the former you get an error. The latter is the equivalent to `-C prefer-dynamic` for the staticlib crate type to indicate that dynamically linking is preferred when both options are available, like for libstd. Care must be taken to ensure that no crate ends up being merged into two distinct staticlibs that are linked together. Doing so will cause a linker error at best and undefined behavior at worst. In addition two distinct staticlibs compiled by different rustc may not be combined under any circumstances due to some rustc private symbols not being mangled. To successfully link a staticlib, `--print native-static-libs` can be used while compiling to ask rustc for the linker flags necessary when linking the staticlib. This is an existing flag which previously only listed native libraries. It has been extended to list rust dylibs too. Trying to locate libstd yourself to link against it is not supported and may break if for example the libstd of multiple rustc versions are put in the same directory. For an example on how to use this see the `src/test/run-make-fulldeps/staticlib-dylib-linkage/` test.
Support TLS access into dylibs on Windows This allows access to `#[thread_local]` in upstream dylibs on Windows by introducing a MIR shim to return the address of the thread local. Accesses that go into an upstream dylib will call the MIR shim to get the address of it. `convert_tls_rvalues` is introduced in `rustc_codegen_ssa` which rewrites MIR TLS accesses to dummy calls which are replaced with calls to the MIR shims when the dummy calls are lowered to backend calls. A new `dll_tls_export` target option enables this behavior with a `false` value which is set for Windows platforms. This fixes rust-lang#84933.
Force parentheses around `match` expression in binary expression This attempts to solve rust-lang#98790.
Place size limits on query keys and values This just prevents these from growing accidentally too large. I'm not sure if there's an easy way to also print the actual size too.
Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time Here, at the same time, there are two `start_llbb` builder, this should be unexpected.
Is this supposed to happen in the dist-various-2 job? It seems to be downloading all the Ubuntu packages in alphabetical order (14,500 and counting). |
💔 Test failed - checks-actions |
apt-cache calls like that return lots of packages on my system too, including 64 different kernel |
@bors retry |
⌛ Testing commit 4561b3b with merge af92a6a6fdd4b34f972492adbcb419b5488aeb2a... |
💔 Test failed - checks-actions |
Error while linking rustdoc, not sure if that is spurious or not, lets find out |
⌛ Testing commit 4561b3b with merge 350e438ab444eb270d24f647bc9707266eba14c6... |
💔 Test failed - checks-actions |
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
Successful merges:
asm!
operands #105798 (Relax ordering rules forasm!
operands)match
expression in binary expression #108542 (Force parentheses aroundmatch
expression in binary expression)start_bx
basic block in codegen from having twoBuilder
s at the same time #108739 (Prevent thestart_bx
basic block in codegen from having twoBuilder
s at the same time)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup