Matthias Krüger [Sat, 7 May 2022 20:44:39 +0000 (22:44 +0200)]
Rollup merge of #96671 - mgeisler:current-exe-docstring, r=Mark-Simulacrum
Remove hard links from `env::current_exe` security example
The security example shows that `env::current_exe` will return the path used when the program was started. This is not really surprising considering how hard links work: after `ln foo bar`, the two files are _equivalent_. It is _not_ the case that `bar` is a “link” to `foo`, nor is `foo` a link to `bar`. They are simply two names for the same underlying data.
The security vulnerability linked to seems to be different: there an attacker would start a SUID binary from a directory under the control of the attacker. The binary would respawn itself by executing the program found at `/proc/self/exe` (which the attacker can control). This is a real problem. In my opinion, the example given here doesn’t really show the same problem, it just shows a misunderstanding of what hard links are.
I looked through the history a bit and found that the example was introduced in https://github.com/rust-lang/rust/pull/33526. That PR actually has two commits, and the first (https://github.com/rust-lang/rust/commit/8478d48dad949b3b1374569a5391089a49094eeb) explains the race condition at the root of the linked security vulnerability. The second commit proceeds to replace the explanation with the example we have today.
This commit reverts most of the second commit from https://github.com/rust-lang/rust/pull/33526.
bors [Sat, 7 May 2022 17:53:59 +0000 (17:53 +0000)]
Auto merge of #96657 - cuviper:time64, r=joshtriplett
Use 64-bit time on 32-bit linux-gnu
The standard library suffered the [Year 2038 problem][Y2038] in two main places on targets with 32-bit `time_t`:
- In `std::time::SystemTime`, we stored a `timespec` that has `time_t` seconds. This is now changed to directly store 64-bit seconds and nanoseconds, and on 32-bit linux-gnu we try to use `__clock_gettime64` (glibc 2.34+) to get the larger timestamp.
- In `std::fs::Metadata`, we store a `stat64`, which has 64-bit `off_t` but still 32-bit `time_t`, and unfortunately that is baked in the API by the (deprecated) `MetadataExt::as_raw_stat()`. However, we can use `statx` for 64-bit `statx_timestamp` to store in addition to the `stat64`, as we already do to support creation time, and the rest of the `MetadataExt` methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support, but that's not something Rust can change.
There remain a few places that need `timespec` for system call timeouts -- I leave that to future work.
bors [Sat, 7 May 2022 13:31:04 +0000 (13:31 +0000)]
Auto merge of #96816 - GuillaumeGomez:rollup-oumn95i, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #96581 (make Size and Align debug-printing a bit more compact)
- #96636 (Fix jump to def regression)
- #96760 (diagnostics: port more diagnostics to derive + add support for `Vec` fields)
- #96788 (Improve validator around field projections and checked bin ops)
- #96805 (Change eslint rules from configuration comments to configuration file)
- #96807 (update Miri)
- #96811 (Fix a minor typo in the description of Formatter)
Guillaume Gomez [Sat, 7 May 2022 13:23:46 +0000 (15:23 +0200)]
Rollup merge of #96760 - davidtwco:diagnostic-translation-vec, r=oli-obk
diagnostics: port more diagnostics to derive + add support for `Vec` fields
- Port "unconstrained opaque type" diagnostic to using the derive.
- Allow `Vec` fields in diagnostic derive - enables support for diagnostics that have multiple primary spans, or have subdiagnostics repeated at multiple locations. `Vec<..>` fields in the diagnostic derive become loops in the generated code.
- Add `create_{err,warning}` - there wasn't a way to create a diagnostic from a struct and not emit it straight away.
- Port "explicit generic args w/ impl trait" diagnostic to using the derive.
Guillaume Gomez [Sat, 7 May 2022 13:23:44 +0000 (15:23 +0200)]
Rollup merge of #96581 - RalfJung:debug-size-align, r=oli-obk
make Size and Align debug-printing a bit more compact
In particular in `{:#?}`-mode, these take up a lot of space, so I think this is the better alternative (even though it is a bit longer in `{:?}` mode, I think it is still more readable).
We could make it even smaller by deviating further from what the actual code looks like, e.g. via something like `Size(4 bytes)`. Not sure what people would think about that?
bors [Sat, 7 May 2022 06:30:29 +0000 (06:30 +0000)]
Auto merge of #96094 - Elliot-Roberts:fix_doctests, r=compiler-errors
Begin fixing all the broken doctests in `compiler/`
Begins to fix #95994.
All of them pass now but 24 of them I've marked with `ignore HELP (<explanation>)` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are.
There are also a few that I marked `ignore` that could maybe be made to work but seem less important.
Each `ignore` has a rough "reason" for ignoring after it parentheses, with
- `(pseudo-rust)` meaning "mostly rust-like but contains foreign syntax"
- `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type), or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy.
- `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting, like MIR.
- `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup.
Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo, there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful.
I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else, I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool
bors [Sat, 7 May 2022 04:15:52 +0000 (04:15 +0000)]
Auto merge of #96804 - compiler-errors:rollup-1mc6aw3, r=compiler-errors
Rollup of 8 pull requests
Successful merges:
- #96660 ([bootstrap] Give a better error when trying to run a path with no registered step)
- #96701 (update `jemallocator` example to use 2018 edition import syntax)
- #96746 (Fix an ICE on #96738)
- #96758 (bootstrap: bsd platform flags for split debuginfo)
- #96778 (Remove closures on `expect_local` to apply `#[track_caller]`)
- #96781 (Fix an incorrect link in The Unstable Book)
- #96783 (Link to correct issue in issue-95034 known-bug)
- #96801 (Add regression test for #96319)
Michael Goulet [Sat, 7 May 2022 03:49:35 +0000 (20:49 -0700)]
Rollup merge of #96781 - koic:fix_an_incorrect_link_in_the_unstable_book, r=ehuss
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
Michael Goulet [Sat, 7 May 2022 03:49:35 +0000 (20:49 -0700)]
Rollup merge of #96778 - JohnTitor:expect-local-track-caller-take-2, r=petrochenkov
Remove closures on `expect_local` to apply `#[track_caller]`
Pointed out in https://github.com/rust-lang/rust/pull/96747#discussion_r866576196
Didn't change `expect_non_local` as I'm not sure if it's also the case.
r? ``@petrochenkov``
Bootstrap currently provides `-Zunstable-options` for OpenBSD when using split debuginfo - this commit provides it for all BSD targets.
We should probably work out a better way of handling the stability of the split debuginfo flag - all options for the flag are unstable but one of them is the default for each platform already.
Michael Goulet [Sat, 7 May 2022 03:49:30 +0000 (20:49 -0700)]
Rollup merge of #96660 - jyn514:better-missing-path-error, r=Mark-Simulacrum
[bootstrap] Give a better error when trying to run a path with no registered step
Before:
```
thread 'main' panicked at 'error: no rules matched invalid', src/bootstrap/builder.rs:287:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
After:
```
error: no `check` rules matched 'invalid'
help: run `x.py check --help --verbose` to show a list of available paths
note: if you are adding a new Step to bootstrap itself, make sure you register it with `describe!`
```
bors [Fri, 6 May 2022 20:14:01 +0000 (20:14 +0000)]
Auto merge of #96785 - GuillaumeGomez:rollup-rgiwa57, r=GuillaumeGomez
Rollup of 10 pull requests
Successful merges:
- #96557 (Allow inline consts to reference generic params)
- #96590 (rustdoc: when running a function-signature search, tweak the tab bar)
- #96650 (Collect function instance used in `global_asm!` sym operand)
- #96733 (turn `append_place_to_string` from recursion into iteration)
- #96748 (Fixes reexports in search)
- #96752 (Put the incompatible_closure_captures lint messages in alphabetical order)
- #96754 (rustdoc: ensure HTML/JS side implementors don't have dups)
- #96772 (Suggest fully qualified path with appropriate params)
- #96776 (Fix two minor issues in hir.rs)
- #96782 (a small `mirror_expr` cleanup)
Guillaume Gomez [Fri, 6 May 2022 18:05:40 +0000 (20:05 +0200)]
Rollup merge of #96733 - SparrowLii:place_to_string, r=davidtwco
turn `append_place_to_string` from recursion into iteration
This PR fixes the FIXME in the impl of `append_place_to_string` which turns `append_place_to_string` from recursion into iteration, meanwhile simplifying the code relatively.
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`.
projects / rust.git / log