Skip to content
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 9 pull requests #97622

Merged
merged 19 commits into from
Jun 1, 2022
Merged

Rollup of 9 pull requests #97622

merged 19 commits into from
Jun 1, 2022

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

RalfJung and others added 19 commits May 20, 2022 15:55
Previously, the `Number` part of the EBNF grammar had an option for `'.' Digit*`, which would include the string "." (a single decimal point). This is not valid, and does not return an Ok as stated. The corrected version removes this, and still allows for the `'.' Digit+` case with the already existing `Digit* '.' Digit+` case.
Expose `get_many_mut` and `get_many_unchecked_mut` to HashMap

This pull-request expose the function [`get_many_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_mut) and [`get_many_unchecked_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_unchecked_mut) from `hashbrown` to the standard library `HashMap` type. They obviously keep the same API and are added under the (new) `map_many_mut` feature.

- `get_many_mut`: Attempts to get mutable references to `N` values in the map at once.
- `get_many_unchecked_mut`: Attempts to get mutable references to `N` values in the map at once, without validating that the values are unique.
Ensure we never consider the null pointer dereferencable

This replaces the checks that are being removed in rust-lang#97188. Those checks were too early and hence incorrect.
simplify code of finding arg index in `opt_const_param_of`

From the FIXME in the impl of `opt_const_param_of`. Part of the code is simplified by blending two iterator statements and using `let...else` statement.
Corrected EBNF grammar for from_str

Hello! This is my first time contributing to an open-source project. I'm excited to have the chance to contribute to the rust community 🥳

I noticed an issue with the documentation for `from_str` in `f32` and `f64`. It states that "All strings that adhere to the following [EBNF](https://www.w3.org/TR/REC-xml/#sec-notation) grammar when lowercased will result in an `Ok` being returned. I believe this is incorrect for the string `"."`, which is valid for the given EBNF grammar, but does not result in an `Ok` being returned ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=09f891aa87963a56d3b0d715d8cbc2b4)). I have simplified the grammar in a way which fixes that, but is otherwise identical.

Previously, the `Number` part of the EBNF grammar had an option for `'.' Digit*`, which would include the string `"."`. This is not valid, and does not return an Ok as stated. The corrected version removes this, and still allows for the `'.' Digit+` case with the already existing `Digit* '.' Digit+` case.
…t_and_unify_type, r=lcnr

Fix comment in `poly_project_and_unify_type`

Renamed some variants to match `ProjectAndUnifyResult`
…rrors

Add regression test for rust-lang#71546

Closes rust-lang#71546
r? `@compiler-errors`
Tweak insert docs

For `{Hash, BTree}Map::insert`, I always have to take a few extra seconds to think about the slight weirdness about the fact that if we "did not" insert (which "sounds" false), we return true, and if we "did" insert, (which "sounds" true), we return false.

This tweaks the doc comments for the `insert` methods of those types (as well as what looks like a rustc internal data structure that I found just by searching the codebase for "If the set did") to first use the "Returns whether _something_" pattern used in e.g. `remove`, where we say that `remove` "returns whether the value was present".
…r=Dylan-DPC

Remove an unnecessary `Option`
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 1, 2022
@JohnTitor
Copy link
Member Author

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Jun 1, 2022

📌 Commit 85fdef0 has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 1, 2022
@bors
Copy link
Contributor

bors commented Jun 1, 2022

⌛ Testing commit 85fdef0 with merge 8256e97...

@bors
Copy link
Contributor

bors commented Jun 1, 2022

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 8256e97 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 1, 2022
@bors bors merged commit 8256e97 into rust-lang:master Jun 1, 2022
@rustbot rustbot added this to the 1.63.0 milestone Jun 1, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8256e97): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results
  • Primary benchmarks: 😿 relevant regression found
  • Secondary benchmarks: 😿 relevant regressions found
mean1 max count2
Regressions 😿
(primary)
3.2% 3.2% 1
Regressions 😿
(secondary)
6.5% 8.6% 2
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) 3.2% 3.2% 1

Cycles

Results
  • Primary benchmarks: 🎉 relevant improvement found
  • Secondary benchmarks: 🎉 relevant improvement found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
N/A N/A 0
Improvements 🎉
(primary)
-3.2% -3.2% 1
Improvements 🎉
(secondary)
-2.4% -2.4% 1
All 😿🎉 (primary) -3.2% -3.2% 1

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2

  2. number of relevant changes 2

@JohnTitor JohnTitor deleted the rollup-4qoxrjn branch June 1, 2022 21:39
@JohnTitor JohnTitor restored the rollup-4qoxrjn branch June 1, 2022 21:46
@JohnTitor JohnTitor deleted the rollup-4qoxrjn branch June 1, 2022 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.