Yuki Okushi [Wed, 1 Jun 2022 14:36:45 +0000 (23:36 +0900)]
Rollup merge of #94647 - Urgau:hash-map-many-mut, r=Amanieu
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.
bors [Wed, 1 Jun 2022 01:49:04 +0000 (01:49 +0000)]
Auto merge of #97435 - Patryk27:bump-compiler-builtins, r=Dylan-DPC
library/std: Bump compiler_builtins
Some neat changes include faster float conversions & fixes for AVR 🙂
(note that's it's my first time upgrading `compiler_builtins`, so I'm not 100% sure if bumping `library/std/Cargo.toml` is enough; certainly seems to be so, though.)
bors [Tue, 31 May 2022 23:24:39 +0000 (23:24 +0000)]
Auto merge of #97600 - matthiaskrgr:rollup-yivyeu5, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #97316 (Put a bound on collection misbehavior)
- #97578 (alloc: remove repeated word in comment)
- #97593 (:arrow_up: rust-analyzer)
- #97596 (Fixup feature name to be more consistent with others)
Matthias Krüger [Tue, 31 May 2022 21:11:35 +0000 (23:11 +0200)]
Rollup merge of #97578 - ojeda:checkpatch, r=JohnTitor
alloc: remove repeated word in comment
Linux's `checkpatch.pl` reports:
```txt
#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+ // - Elements are :Copy so it's OK to to copy them, without doing
```
Matthias Krüger [Tue, 31 May 2022 21:11:34 +0000 (23:11 +0200)]
Rollup merge of #97316 - CAD97:bound-misbehavior, r=dtolnay
Put a bound on collection misbehavior
As currently written, when a logic error occurs in a collection's trait parameters, this allows *completely arbitrary* misbehavior, so long as it does not cause undefined behavior in std. However, because the extent of misbehavior is not specified, it is allowed for *any* code in std to start misbehaving in arbitrary ways which are not formally UB; consider the theoretical example of a global which gets set on an observed logic error. Because the misbehavior is only bound by not resulting in UB from safe APIs and the crate-level encapsulation boundary of all of std, this makes writing user unsafe code that utilizes std theoretically impossible, as it now relies on undocumented QOI (quality of implementation) that unrelated parts of std cannot be caused to misbehave by a misuse of std::collections APIs.
In practice, this is a nonconcern, because std has reasonable QOI and an implementation that takes advantage of this freedom is essentially a malicious implementation and only compliant by the most langauage-lawyer reading of the documentation.
To close this hole, we just add a small clause to the existing logic error paragraph that ensures that any misbehavior is limited to the collection which observed the logic error, making it more plausible to prove the soundness of user unsafe code.
This is not meant to be formal; a formal refinement would likely need to mention that values derived from the collection can also misbehave after a logic error is observed, as well as define what it means to "observe" a logic error in the first place. This fix errs on the side of informality in order to close the hole without complicating a normal reading which can assume a reasonable nonmalicious QOI.
bors [Tue, 31 May 2022 17:59:41 +0000 (17:59 +0000)]
Auto merge of #97570 - JakobDegen:dse-test, r=tmiasko
Fix TLS access mir opt test and remove stale files
Thanks `@pietroalbini` for noticing that the TLS test was not doing what it was supposed to. Switched to `PreCodegen` because `SimplifyCfg` does not run on opt level 0.
Tracking issue: #89792.
Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`.
Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`.
bors [Tue, 31 May 2022 12:14:51 +0000 (12:14 +0000)]
Auto merge of #97521 - SkiFire13:clarify-vec-as-ptr, r=Dylan-DPC
Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation
Currently the documentation says they return a pointer to the vector's buffer, which has the implied precondition that the vector allocated some memory. However `Vec`'s documentation also specifies that it won't always allocate, so it's unclear whether the pointer returned is valid in that case. Of course you won't be able to read/write actual bytes to/from it since the capacity is 0, but there's an exception: zero sized read/writes. They are still valid as long as the pointer is not null and the memory it points to wasn't deallocated, but `Vec::as_ptr` and `Vec::as_mut_ptr` don't specify that's not the case. This PR thus specifies they are actually valid for zero sized reads since `Vec` is implemented to hold a dangling pointer in those cases, which is neither null nor was deallocated.
Miguel Ojeda [Tue, 31 May 2022 10:28:57 +0000 (12:28 +0200)]
alloc: remove repeated word in comment
Linux's `checkpatch.pl` reports:
```txt
#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+ // - Elements are :Copy so it's OK to to copy them, without doing
```
bors [Tue, 31 May 2022 09:34:00 +0000 (09:34 +0000)]
Auto merge of #97526 - Nilstrieb:unicode-is-printable-fastpath, r=joshtriplett
Add unicode fast path to `is_printable`
Before, it would enter the full expensive check even for normal ascii characters. Now, it skips the check for the ascii characters in `32..127`. This range was checked manually from the current behavior.
I ran the `tracing` test suite in miri, and it was really slow. I looked at a profile, and miri spent most of the time in `core::char::methods::escape_debug_ext`, where half of that was dominated by `core::unicode::printable::is_printable`. So I optimized it here.
Nilstrieb [Sun, 29 May 2022 17:21:57 +0000 (19:21 +0200)]
Add unicode fast path to `is_printable`
Before, it would enter the full expensive check even for normal ascii
characters. Now, it skips the check for the ascii characters in
`32..127`. This range was checked manually from the current behavior.
bors [Tue, 31 May 2022 06:53:02 +0000 (06:53 +0000)]
Auto merge of #97574 - Dylan-DPC:rollup-jq850l6, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #97089 (Improve settings theme display)
- #97229 (Document the current aliasing rules for `Box<T>`.)
- #97371 (Suggest adding a semicolon to a closure without block)
- #97455 (Stabilize `toowned_clone_into`)
- #97565 (Add doc alias `memset` to `write_bytes`)
- #97569 (Remove `memset` alias from `fill_with`.)
Dylan DPC [Tue, 31 May 2022 05:57:37 +0000 (07:57 +0200)]
Rollup merge of #97569 - thomcc:fill_with_isnt_memset, r=Amanieu
Remove `memset` alias from `fill_with`.
In https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Unsafe.20and.20Safe.20versions.20of.20APIs.20both.20getting.20the.20same.20alias/near/284413029 `@Amanieu` pointed out that we had this, which is not really right.
In our guidelines we say that we will "not add an alias for a function that's only somewhat similar or related", which applies here. Memset doesn't take a closure, not even conceptually.
Dylan DPC [Tue, 31 May 2022 05:57:36 +0000 (07:57 +0200)]
Rollup merge of #97565 - lukas-code:patch-1, r=thomcc
Add doc alias `memset` to `write_bytes`
I were looking for `memset` in rust, but the docs only pointed me to `slice::fill`.
With only the old aliases, one might write code like this, which is incorrect if the memory is uninitialized.
``` Rust
core::slice::from_raw_parts(ptr, len).fill(0)
```
Dylan DPC [Tue, 31 May 2022 05:57:33 +0000 (07:57 +0200)]
Rollup merge of #97229 - Nilstrieb:doc-box-noalias, r=dtolnay
Document the current aliasing rules for `Box<T>`.
Currently, `Box<T>` gets `noalias`, meaning it has the same rules as `&mut T`. This is sparsely documented, even though it can have quite a big impact on unsafe code using box. Therefore, these rules are documented here, with a big warning that they are not normative and subject to change, since we have not yet committed to an aliasing model and the state of `Box<T>` is especially uncertain.
If you have any suggestions and improvements, make sure to leave them here. This is mostly intended to inform people about what is currently going on (to prevent misunderstandings such as [Jon Gjengset's Box aliasing](https://www.youtube.com/watch?v=EY7Wi9fV5bk)).
This is supposed to _only document current UB_ and not add any new guarantees or rules.
bors [Tue, 31 May 2022 01:17:00 +0000 (01:17 +0000)]
Auto merge of #97566 - compiler-errors:rollup-qfxw4j8, r=compiler-errors
Rollup of 6 pull requests
Successful merges:
- #89685 (refactor: VecDeques Iter fields to private)
- #97172 (Optimize the diagnostic generation for `extern unsafe`)
- #97395 (Miri call ABI check: ensure type size+align stay the same)
- #97431 (don't do `Sized` and other return type checks on RPIT's real type)
- #97555 (Source code page: line number click adds `NaN`)
- #97558 (Fix typos in comment)
Michael Goulet [Mon, 30 May 2022 22:57:30 +0000 (15:57 -0700)]
Rollup merge of #97555 - GuillaumeGomez:line-number-click, r=notriddle
Source code page: line number click adds `NaN`
When you click on the parent element of the line numbers in the source code pages, it'll add `NaN` (like in https://doc.rust-lang.org/nightly/src/alloc/lib.rs.html#NaN). This PR fixes this bug.
Michael Goulet [Mon, 30 May 2022 22:57:29 +0000 (15:57 -0700)]
Rollup merge of #97431 - compiler-errors:issue-97413, r=oli-obk
don't do `Sized` and other return type checks on RPIT's real type
Fixes an ICE where we're doing `Sized` check against the RPIT's real type, instead of against the opaque type. This differs from what we're doing in MIR typeck, which causes ICE #97226.
This regressed in #96516 -- this adjusts that fix to be a bit more conservative. That PR was backported and thus the ICE is also present in stable. Not sure if it's worth to beta and/or stable backport, probably not the latter but I could believe the former.
r? `@oli-obk`
cc: another attempt to fix this ICE #97413. I believe this PR addresses the root cause.
Michael Goulet [Mon, 30 May 2022 22:57:28 +0000 (15:57 -0700)]
Rollup merge of #97395 - RalfJung:call-abi, r=oli-obk
Miri call ABI check: ensure type size+align stay the same
We should almost certainly not accept calls where caller and callee disagree on the size or alignment of the type.
The checks we do *almost* imply that, except that `ScalarPair` types can have `repr(align)` and thus differ in size/align even when they are pairs of the same primitive type.
Michael Goulet [Mon, 30 May 2022 22:57:27 +0000 (15:57 -0700)]
Rollup merge of #97172 - SparrowLii:unsafe_extern, r=compiler-errors
Optimize the diagnostic generation for `extern unsafe`
This PR does the following about diagnostic generation when parsing foreign mod:
1. Fixes the FIXME about avoiding depending on the error message text.
2. Continue parsing when `unsafe` is followed by `{` (just like `unsafe extern {...}`).
3. Add test case.
Michael Goulet [Mon, 30 May 2022 22:57:27 +0000 (15:57 -0700)]
Rollup merge of #89685 - DeveloperC286:iter_fields_to_private, r=oli-obk
refactor: VecDeques Iter fields to private
Made the fields of VecDeque's Iter private by creating a Iter::new(...) function to create a new instance of Iter and migrating usage to use Iter::new(...).
bors [Mon, 30 May 2022 22:49:36 +0000 (22:49 +0000)]
Auto merge of #97357 - davidtwco:diagnostic-translation-typed-subdiagnostic-simplification, r=oli-obk
errors: simplify referring to fluent attributes
To render the message of a Fluent attribute, the identifier of the Fluent message must be known. `DiagnosticMessage::FluentIdentifier` contains both the message's identifier and optionally the identifier of an attribute. Generated constants for each attribute would therefore need to be named uniquely (amongst all error messages) or be able to refer to only the attribute identifier which will be combined with a message identifier later. In this commit, the latter strategy is implemented as part of the `Diagnostic` type's functions for adding subdiagnostics of various kinds.
bors [Mon, 30 May 2022 17:39:58 +0000 (17:39 +0000)]
Auto merge of #97480 - conradludgate:faster-format-literals, r=joshtriplett
improve format impl for literals
The basic idea of this change can be seen here https://godbolt.org/z/MT37cWoe1.
Updates the format impl to have a fast path for string literals and the default path for regular format args.
This change will allow `format!("string literal")` to be used interchangably with `"string literal".to_owned()`.
This would be relevant in the case of `f!"string literal"` being legal (https://github.com/rust-lang/rfcs/pull/3267) in which case it would be the easiest way to create owned strings from literals, while also being just as efficient as any other impl
David Wood [Tue, 24 May 2022 14:09:47 +0000 (15:09 +0100)]
errors: simplify referring to fluent attributes
To render the message of a Fluent attribute, the identifier of the
Fluent message must be known. `DiagnosticMessage::FluentIdentifier`
contains both the message's identifier and optionally the identifier of
an attribute. Generated constants for each attribute would therefore
need to be named uniquely (amongst all error messages) or be able to
refer to only the attribute identifier which will be combined with a
message identifier later. In this commit, the latter strategy is
implemented as part of the `Diagnostic` type's functions for adding
subdiagnostics of various kinds.
Dylan DPC [Mon, 30 May 2022 12:33:53 +0000 (14:33 +0200)]
Rollup merge of #97545 - thomcc:sip-comment-safety, r=Dylan-DPC
Reword safety comments in core/hash/sip.rs
In https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Is.20there.20any.20way.20to.20soundly.20do.20a.20masked.20out-of-bounds.20read.3F/near/284329248 it came up that this is using an atypical (and somewhat vague) phrasing of the safety requirement, so this slightly rewords it.
Dylan DPC [Mon, 30 May 2022 12:33:50 +0000 (14:33 +0200)]
Rollup merge of #97504 - JohnTitor:cleanup-deps, r=davidtwco
Ensure source file present when calculating max line number
Resubmission of #89268, fixes #71363
The behavior difference of `simulate-remapped-rust-src-base` is not something we should take into account here, so limiting targets to run the test makes sense, I think.
r? `@davidtwco,` and `@estebank,` you might be interested in this change
Dylan DPC [Mon, 30 May 2022 12:33:49 +0000 (14:33 +0200)]
Rollup merge of #97499 - est31:master, r=Dylan-DPC
Remove "sys isn't exported yet" phrase
The oldest occurence is from 9e224c2bf18ebf8f871efb2e1aba43ed7970ebb7,
which is from the pre-1.0 days. In the years since then, std::sys still
hasn't been exported, and the last attempt was met with strong criticism:
https://github.com/rust-lang/rust/pull/97151
Thus, removing the "yet" part makes a lot of sense.
Dylan DPC [Mon, 30 May 2022 12:33:48 +0000 (14:33 +0200)]
Rollup merge of #97494 - est31:remove_box_alloc_tests, r=Dylan-DPC
Use Box::new() instead of box syntax in library tests
The tests inside `library/*` have no reason to use `box` syntax as they have 0 performance relevance. Therefore, we can safely remove them (instead of having to use alternatives like the one in #97293).
est31 [Sat, 28 May 2022 23:00:24 +0000 (01:00 +0200)]
Remove "sys isn't exported yet" phrase
The oldest occurence is from 9e224c2bf18ebf8f871efb2e1aba43ed7970ebb7,
which is from the pre-1.0 days. In the years since then, std::sys still
hasn't been exported, and the last attempt was met with strong criticism:
https://github.com/rust-lang/rust/pull/97151
Thus, removing the "yet" part makes a lot of sense.
bors [Mon, 30 May 2022 09:19:03 +0000 (09:19 +0000)]
Auto merge of #96964 - oli-obk:const_trait_mvp, r=compiler-errors
Replace `#[default_method_body_is_const]` with `#[const_trait]`
pulled out of #96077
related issues: #67792 and #92158
cc `@fee1-dead`
This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).
bors [Sun, 29 May 2022 23:25:51 +0000 (23:25 +0000)]
Auto merge of #97538 - compiler-errors:rollup-zp3ukke, r=compiler-errors
Rollup of 4 pull requests
Successful merges:
- #97493 (Use `type_is_copy_modulo_regions` check in intrisicck)
- #97518 (Fix order of closing HTML elements in rustdoc output)
- #97530 (Add more eslint checks)
- #97536 (Remove unused lifetimes from expand_macro)