Rollup of 6 pull requests #96214
Merged
Rollup of 6 pull requests #96214
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`--extern-location` was an experiment to investigate the best way to generate useful diagnostics for unused dependency warnings by enabling a build system to identify the corresponding build config. While I did successfully use this, I've since been convinced the alternative `--json unused-externs` mechanism is the way to go, and there's no point in having two mechanisms with basically the same functionality. This effectively reverts rust-lang#72603
The `vec!` macro has 3 rules, but two are not usable under `no_global_oom_handling` builds of the standard library (even with a zero size): ```rust let _ = vec![42]; // Error: requires `exchange_malloc` lang_item. let _ = vec![42; 0]; // Error: cannot find function `from_elem`. ``` Thus those two rules should not be available to begin with. The remaining one, with an empty matcher, is just a shorthand for `new()` and may not make as much sense to have alone, since the idea behind `vec!` is to enable `Vec`s to be defined with the same syntax as array expressions. Furthermore, the documentation can be confusing since it shows the other rules. Thus perhaps it is better and simpler to disable `vec!` entirely under `no_global_oom_handling` environments, and let users call `new()` instead: ```rust let _: Vec<i32> = vec![]; let _: Vec<i32> = Vec::new(); ``` Notwithstanding this, a `try_vec!` macro would be useful, such as the one introduced in rust-lang#95051. If the shorthand for `new()` is deemed worth keeping on its own, then it may be interesting to have a separate `vec!` macro with a single rule and different, simpler documentation. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…in a foreign crate Adding diagnostic data on generators to the crate metadata and using it to provide a better diagnostic on failure to meet send bound on futures originated from a foreign crate
`CRATE_DEF_ID` and `CrateNum::as_def_id` are almost always what we want.
…c_fn_in_foreign_crate_diag_2, r=davidtwco Improved diagnostic on failure to meet send bound on future in a foreign crate Provide a better diagnostic on failure to meet send bound on futures in a foreign crate. fixes rust-lang#78543
…lacrum Fix typo in bootstrap.py
…dtwco Remove `--extern-location` and all associated code `--extern-location` was an experiment to investigate the best way to generate useful diagnostics for unused dependency warnings by enabling a build system to identify the corresponding build config. While I did successfully use this, I've since been convinced the alternative `--json unused-externs` mechanism is the way to go, and there's no point in having two mechanisms with basically the same functionality. This effectively reverts rust-lang#72603
…, r=Mark-Simulacrum `alloc`: make `vec!` unavailable under `no_global_oom_handling` `alloc`: make `vec!` unavailable under `no_global_oom_handling` The `vec!` macro has 3 rules, but two are not usable under `no_global_oom_handling` builds of the standard library (even with a zero size): ```rust let _ = vec![42]; // Error: requires `exchange_malloc` lang_item. let _ = vec![42; 0]; // Error: cannot find function `from_elem`. ``` Thus those two rules should not be available to begin with. The remaining one, with an empty matcher, is just a shorthand for `new()` and may not make as much sense to have alone, since the idea behind `vec!` is to enable `Vec`s to be defined with the same syntax as array expressions. Furthermore, the documentation can be confusing since it shows the other rules. Thus perhaps it is better and simpler to disable `vec!` entirely under `no_global_oom_handling` environments, and let users call `new()` instead: ```rust let _: Vec<i32> = vec![]; let _: Vec<i32> = Vec::new(); ``` Notwithstanding this, a `try_vec!` macro would be useful, such as the one introduced in rust-lang#95051. If the shorthand for `new()` is deemed worth keeping on its own, then it may be interesting to have a separate `vec!` macro with a single rule and different, simpler documentation. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…stion-to-add-slice-in-pattern-matching, r=nagisa Fix an invalid error for a suggestion to add a slice in pattern-matching closes rust-lang#96103
…ochenkov Stop using CRATE_DEF_INDEX outside of metadata encoding. `CRATE_DEF_ID` and `CrateNum::as_def_id` are almost always what we want. We should not manipulate raw `DefIndex` outside of metadata encoding.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
|
📌 Commit 9fad214 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Apr 19, 2022
This was referenced Apr 19, 2022
|
Finished benchmarking commit (4ca19e0): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
|
Visiting for performance triage
There's next to no change between the merge commit measured here and the merge commit preceding it (which was from #96020) So I think there's something flaky in our perf bot.
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
--extern-locationand all associated code #96086 (Remove--extern-locationand all associated code)alloc: makevec!unavailable underno_global_oom_handling#96089 (alloc: makevec!unavailable underno_global_oom_handling)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup