-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 #108464
Rollup of 7 pull requests #108464
Conversation
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives. This is another way to address issue # rust-lang#70093, which is currently addressed by `-Zlink-native-libraries` (implemented in rust-lang#70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used. Being able to control this on a crate-by-crate basis should make it much easier to apply when needed. I'm not sure if we need both mechanisms, but we can decide that later.
…l-testing, r=jyn514 Test that the compiler/library builds with validate-mir Fixes rust-lang#105706
…=estebank [breaking change] Remove a rustdoc back compat warning This warning was introduced in rust-lang#62855 for users who use `rustdoc` directly on proc macro crates (instead of using `cargo doc`) without passing `--crate-type proc-macro` (which `cargo doc` passed automatically).
Implement -Zlink-directives=yes/no `-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives. This is another way to address issue # rust-lang#70093, which is currently addressed by `-Zlink-native-libraries` (implemented in rust-lang#70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used. Being able to control this on a crate-by-crate basis should make it much easier to apply when needed. I'm not sure if we need both mechanisms, but we can decide that later. cc `@pcwalton` `@cramertj`
…Simulacrum Split `x setup` sub-actions to CLI arguments Closes rust-lang#107846 This adds a new `none` profile option which simply skips the `config.toml` step. It also adds `hook` and `vscode` subcommands, for installing the pre-push hook and getting `settings.json` respectively.
…er-errors Add check for invalid #[macro_export] arguments Resolves rust-lang#107231 Sorry if I made something wrong, this is my first contribution to the repo.
…mulacrum [107049] Recognise top level keys in config.toml.example Closes rust-lang#107049 Test Plan Configure changelog-seen ``` lionellloh@lionellloh-mbp rust % ./configure --set changelog-seen=1 configure: processing command line configure: configure: changelog-seen := 1 configure: build.configure-args := ['--set', 'changelog-seen=1'] configure: configure: writing `config.toml` in current directory configure: configure: run `python /Users/lionellloh/rust/x.py --help` lionellloh@lionellloh-mbp rust % diff config.toml config.toml.example 16c16 < changelog-seen = 1 --- > changelog-seen = 2 331c331 < configure-args = ['--set', 'changelog-seen=1'] --- > #configure-args = [] 675c675 < [target.x86_64-apple-darwin] --- > [target.x86_64-unknown-linux-gnu] 809d808 < ``` Configure profile ``` lionellloh@lionellloh-mbp rust % ./configure --set profile=xyz configure: processing command line configure: configure: profile := xyz configure: build.configure-args := ['--set', 'profile=xyz'] configure: configure: writing `config.toml` in current directory configure: configure: run `python /Users/lionellloh/rust/x.py --help` lionellloh@lionellloh-mbp rust % diff config.toml config.toml.example 26c26 < profile = xyz --- > #profile = <none> 331c331 < configure-args = ['--set', 'profile=xyz'] --- > #configure-args = [] 675c675 < [target.x86_64-apple-darwin] --- > [target.x86_64-unknown-linux-gnu] 809d808 < ```
…sound, r=lcnr Make object bound candidates sound in the new trait solver r? `@lcnr`
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 34e6673a04 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (f37f9f6): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. |
The single small regression is outweighed by a few small improvements. No further investigation needed. @rustbot label: +perf-regression-triaged |
Successful merges:
x setup
sub-actions to CLI arguments #107848 (Splitx setup
sub-actions to CLI arguments)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup