Guillaume Gomez [Fri, 6 May 2022 18:05:37 +0000 (20:05 +0200)]
Rollup merge of #96557 - nbdd0121:const, r=oli-obk
Allow inline consts to reference generic params
Tracking issue: #76001
The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well.
However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have:
```rust
fn foo<T>() {
let x = [4i32; std::mem::size_of::<T>()]; // NOT ALLOWED (for now)
let x = const { std::mem::size_of::<T>() }; // ALLOWED with this PR!
let x = [4i32; const { std::mem::size_of::<T>() }]; // NOT ALLOWED (for now)
}
```
This would make inline consts super useful for compile-time checks and assertions:
```rust
fn assert_zst<T>() {
const { assert!(std::mem::size_of::<T>() == 0) };
}
```
This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do:
```rust
fn assert_zst<T>() {
struct F<T>(T);
impl<T> F<T> {
const V: () = assert!(std::mem::size_of::<T>() == 0);
}
let _ = F::<T>::V;
}
```
It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either:
```rust
fn foo<T>() -> usize {
let (_, size): (PhantomData<T>, usize) = const {
const fn my_size_of<T>() -> (PhantomData<T>, usize) {
(PhantomData, std::mem::size_of::<T>())
}
my_size_of()
};
size
}
```
Koichi ITO [Fri, 6 May 2022 16:21:40 +0000 (01:21 +0900)]
Fix an incorrect link in The Unstable Book
https://github.com/rust-lang/rust/blob/master/src/librustc_session/lint/builtin.rs
returns page not found.
The following is the background of the move.
First https://github.com/rust-lang/rust/pull/74862 moves from src/librustc_session/lint/builtin.rs
to compiler/rustc_session/src/lint/builtin.rs
Then https://github.com/rust-lang/rust/commit/23018a5 moves from compiler/rustc_session/src/lint/builtin.rs
to compiler/rustc_lint_defs/src/builtin.rs
So, the current correct link is https://github.com/rust-lang/rust/blob/master/compiler/rustc_lint_defs/src/builtin.rs
This PR fixes a broken link on the following page:
https://doc.rust-lang.org/beta/unstable-book/language-features/plugin.html
bors [Fri, 6 May 2022 14:53:24 +0000 (14:53 +0000)]
Auto merge of #95183 - ibraheemdev:arc-count-acquire, r=Amanieu
Weaken needlessly restrictive orderings on `Arc::*_count`
There is no apparent reason for these to be `SeqCst`. For reference, [the Boost C++ implementation relies on acquire semantics](https://github.com/boostorg/smart_ptr/blob/f2cc84a23c64b8a73c9b72b34799d0854d7e0787/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp#L137-L140).
bors [Fri, 6 May 2022 09:43:57 +0000 (09:43 +0000)]
Auto merge of #94598 - scottmcm:prefix-free-hasher-methods, r=Amanieu
Add a dedicated length-prefixing method to `Hasher`
This accomplishes two main goals:
- Make it clear who is responsible for prefix-freedom, including how they should do it
- Make it feasible for a `Hasher` that *doesn't* care about Hash-DoS resistance to get better performance by not hashing lengths
This does not change rustc-hash, since that's in an external crate, but that could potentially use it in future.
Fixes #94026
r? rust-lang/libs
---
The core of this change is the following two new methods on `Hasher`:
```rust
pub trait Hasher {
/// Writes a length prefix into this hasher, as part of being prefix-free.
///
/// If you're implementing [`Hash`] for a custom collection, call this before
/// writing its contents to this `Hasher`. That way
/// `(collection![1, 2, 3], collection![4, 5])` and
/// `(collection![1, 2], collection![3, 4, 5])` will provide different
/// sequences of values to the `Hasher`
///
/// The `impl<T> Hash for [T]` includes a call to this method, so if you're
/// hashing a slice (or array or vector) via its `Hash::hash` method,
/// you should **not** call this yourself.
///
/// This method is only for providing domain separation. If you want to
/// hash a `usize` that represents part of the *data*, then it's important
/// that you pass it to [`Hasher::write_usize`] instead of to this method.
///
/// # Examples
///
/// ```
/// #![feature(hasher_prefixfree_extras)]
/// # // Stubs to make the `impl` below pass the compiler
/// # struct MyCollection<T>(Option<T>);
/// # impl<T> MyCollection<T> {
/// # fn len(&self) -> usize { todo!() }
/// # }
/// # impl<'a, T> IntoIterator for &'a MyCollection<T> {
/// # type Item = T;
/// # type IntoIter = std::iter::Empty<T>;
/// # fn into_iter(self) -> Self::IntoIter { todo!() }
/// # }
///
/// use std::hash::{Hash, Hasher};
/// impl<T: Hash> Hash for MyCollection<T> {
/// fn hash<H: Hasher>(&self, state: &mut H) {
/// state.write_length_prefix(self.len());
/// for elt in self {
/// elt.hash(state);
/// }
/// }
/// }
/// ```
///
/// # Note to Implementers
///
/// If you've decided that your `Hasher` is willing to be susceptible to
/// Hash-DoS attacks, then you might consider skipping hashing some or all
/// of the `len` provided in the name of increased performance.
#[inline]
#[unstable(feature = "hasher_prefixfree_extras", issue = "88888888")]
fn write_length_prefix(&mut self, len: usize) {
self.write_usize(len);
}
/// Writes a single `str` into this hasher.
///
/// If you're implementing [`Hash`], you generally do not need to call this,
/// as the `impl Hash for str` does, so you can just use that.
///
/// This includes the domain separator for prefix-freedom, so you should
/// **not** call `Self::write_length_prefix` before calling this.
///
/// # Note to Implementers
///
/// The default implementation of this method includes a call to
/// [`Self::write_length_prefix`], so if your implementation of `Hasher`
/// doesn't care about prefix-freedom and you've thus overridden
/// that method to do nothing, there's no need to override this one.
///
/// This method is available to be overridden separately from the others
/// as `str` being UTF-8 means that it never contains `0xFF` bytes, which
/// can be used to provide prefix-freedom cheaper than hashing a length.
///
/// For example, if your `Hasher` works byte-by-byte (perhaps by accumulating
/// them into a buffer), then you can hash the bytes of the `str` followed
/// by a single `0xFF` byte.
///
/// If your `Hasher` works in chunks, you can also do this by being careful
/// about how you pad partial chunks. If the chunks are padded with `0x00`
/// bytes then just hashing an extra `0xFF` byte doesn't necessarily
/// provide prefix-freedom, as `"ab"` and `"ab\u{0}"` would likely hash
/// the same sequence of chunks. But if you pad with `0xFF` bytes instead,
/// ensuring at least one padding byte, then it can often provide
/// prefix-freedom cheaper than hashing the length would.
#[inline]
#[unstable(feature = "hasher_prefixfree_extras", issue = "88888888")]
fn write_str(&mut self, s: &str) {
self.write_length_prefix(s.len());
self.write(s.as_bytes());
}
}
```
With updates to the `Hash` implementations for slices and containers to call `write_length_prefix` instead of `write_usize`.
`write_str` defaults to using `write_length_prefix` since, as was pointed out in the issue, the `write_u8(0xFF)` approach is insufficient for hashers that work in chunks, as those would hash `"a\u{0}"` and `"a"` to the same thing. But since `SipHash` works byte-wise (there's an internal buffer to accumulate bytes until a full chunk is available) it overrides `write_str` to continue to use the add-non-UTF-8-byte approach.
---
Compatibility:
Because the default implementation of `write_length_prefix` calls `write_usize`, the changed hash implementation for slices will do the same thing the old one did on existing `Hasher`s.
Scott McMurray [Fri, 6 May 2022 06:18:11 +0000 (23:18 -0700)]
For now, don't change the details of hashing a `str`
We might want to change the default before stabilizing (or maybe even after), but for getting in the new unstable methods, leave it as-is for now. That way it won't break cargo and such.
Scott McMurray [Fri, 4 Mar 2022 08:17:26 +0000 (00:17 -0800)]
Add a dedicated length-prefixing method to `Hasher`
This accomplishes two main goals:
- Make it clear who is responsible for prefix-freedom, including how they should do it
- Make it feasible for a `Hasher` that *doesn't* care about Hash-DoS resistance to get better performance by not hashing lengths
This does not change rustc-hash, since that's in an external crate, but that could potentially use it in future.
bors [Fri, 6 May 2022 04:56:23 +0000 (04:56 +0000)]
Auto merge of #96759 - compiler-errors:rollup-p4jtm92, r=compiler-errors
Rollup of 7 pull requests
Successful merges:
- #96174 (mark ptr-int-transmute test as no_run)
- #96639 (Fix typo in `offset_from` documentation)
- #96704 (Add rotation animation on settings button when loading)
- #96730 (Add a regression test for #64173 and #66152)
- #96741 (Improve settings loading strategy)
- #96744 (Implement [OsStr]::join)
- #96747 (Add `track_caller` to `DefId::expect_local()`)
David Wood [Fri, 6 May 2022 02:44:41 +0000 (03:44 +0100)]
sess: add `create_{err,warning}`
Currently, the only API for creating errors from a diagnostic derive
will emit it immediately. This makes it difficult to add subdiagnostics
to diagnostics from the derive, so add `create_{err,warning}` functions
that return the diagnostic without emitting it.
David Wood [Fri, 6 May 2022 02:43:30 +0000 (03:43 +0100)]
macros: allow `Vec` fields in diagnostic derive
Diagnostics can have multiple primary spans, or have subdiagnostics
repeated at multiple locations, so support `Vec<..>` fields in the
diagnostic derive which become loops in the generated code.
Michael Goulet [Fri, 6 May 2022 02:34:27 +0000 (19:34 -0700)]
Rollup merge of #96747 - JohnTitor:expect-local-track-caller, r=compiler-errors
Add `track_caller` to `DefId::expect_local()`
Suggested in https://github.com/rust-lang/rust/issues/96738#issuecomment-1118961888.
`DefId::expect_local()` often causes ICEs (panics) and should be a good candidate to add `track_caller`.
Michael Goulet [Fri, 6 May 2022 02:34:24 +0000 (19:34 -0700)]
Rollup merge of #96704 - GuillaumeGomez:rotation-animation, r=jsha
Add rotation animation on settings button when loading
As discussed, I added an animation when the settings JS file is loading (I voluntarily made the timeout at the end of the `settings.js` super long so we can see what the animation looks like):
Michael Goulet [Fri, 6 May 2022 02:34:23 +0000 (19:34 -0700)]
Rollup merge of #96639 - adpaco-aws:fix-offset-from-typo, r=scottmcm
Fix typo in `offset_from` documentation
Small fix for what I think is a typo in the `offset_from` documentation.
Someone reading this may understand that the distance in bytes is obtained by dividing the distance by `mem::size_of::<T>()`, but here we just want to define "units of T" in terms of bytes (i.e., units of T == bytes / `mem::size_of::<T>()`).
Michael Goulet [Fri, 6 May 2022 02:34:22 +0000 (19:34 -0700)]
Rollup merge of #96174 - RalfJung:no-run-transmute, r=scottmcm
mark ptr-int-transmute test as no_run
This causes [CI failures in Miri](https://github.com/rust-lang/miri-test-libstd/runs/6062500259?check_suite_focus=true) since ptr-int-transmutes are rejected there (when strict provenance is enabled).
Aaron Hill [Wed, 27 Apr 2022 00:34:58 +0000 (20:34 -0400)]
Don't cache results of coinductive cycle
Fixes #96319
The logic around handling co-inductive cycles in the evaluation cache
is confusing and error prone. Fortunately, a perf run showed that it
doesn't actually appear to improve performance, so we can simplify
this code (and eliminate a source of ICEs) by just skipping caching
the evaluation results for co-inductive cycle participants.
This commit makes no changes to any of the other logic around
co-inductive cycle handling. Thus, while this commit could
potentially expose latent bugs that were being hidden by
caching, it should not introduce any new bugs.
bors [Thu, 5 May 2022 16:59:54 +0000 (16:59 +0000)]
Auto merge of #96734 - matthiaskrgr:rollup-hng33tb, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #95359 (Update `int_roundings` methods from feedback)
- #95843 (Improve Rc::new_cyclic and Arc::new_cyclic documentation)
- #96507 (Suggest calling `Self::associated_function()`)
- #96635 (Use "strict" mode in JS scripts)
- #96673 (Report that opaque types are not allowed in impls even in the presence of other errors)
- #96682 (Show invisible delimeters (within comments) when pretty printing.)
- #96714 (interpret/validity: debug-check ScalarPair layout information)
Michael Howell [Mon, 2 May 2022 16:45:32 +0000 (09:45 -0700)]
rustdoc: change the "In Function Signatures" to context-sensitive
* If it's just `-> a`, use "In Function Return Types"
* If it's just `a b`, use "In Function Parameters"
* Otherwise, still use "In Function Signatures"
Matthias Krüger [Thu, 5 May 2022 13:43:05 +0000 (15:43 +0200)]
Rollup merge of #96673 - oli-obk:tait_impl_diagnostic, r=petrochenkov
Report that opaque types are not allowed in impls even in the presence of other errors
fixes #96569
before this PR those useful errors were hidden because either `unused parameter` or `only traits defined in the current crate can be implemented for arbitrary types` got emitted first.
Matthias Krüger [Thu, 5 May 2022 13:43:00 +0000 (15:43 +0200)]
Rollup merge of #95359 - jhpratt:int_roundings, r=joshtriplett
Update `int_roundings` methods from feedback
This updates `#![feature(int_roundings)]` (#88581) from feedback. All methods now take `NonZeroX`. The documentation makes clear that they panic in debug mode and wrap in release mode.
bors [Thu, 5 May 2022 13:12:09 +0000 (13:12 +0000)]
Auto merge of #8788 - flip1995:rustup, r=xFrednet,flip1995
Rustup
r? `@ghost`
changelog: move trait_duplication_in_bounds and type_repetition_in_bounds to nursery temporarily. This could already be reverted before the release. Check the Clippy in the Rust repo beta branch when writing this changelog.
flip1995 [Thu, 5 May 2022 12:32:31 +0000 (13:32 +0100)]
HACK: Move buggy lints to nursery
Those lints are trait_duplication_in_bounds and
type_repetition_in_bounds. I don't think those can be fixed on the
Clippy side alone, but need changes in the compiler. So let's move them
to nursery to get the sync through and then fix them on the rustc side.
Also adds a regression test that has to be fixed before they can be
moved back to pedantic.