bors [Mon, 2 Aug 2021 13:31:02 +0000 (13:31 +0000)]
Auto merge of #87248 - RalfJung:ctfe-partial-overwrite, r=oli-obk
CTFE: throw unsupported error when partially overwriting a pointer
Currently, during CTFE, when a write to memory would overwrite parts of a pointer, we make the remaining parts of that pointer "uninitialized". This is probably not what users expect, so if this ever happens they will be quite confused about why some of the data just vanishes for seemingly no good reason.
So I propose we change this to abort CTFE when that happens, to at last avoid silently doing the wrong thing.
Cc https://github.com/rust-lang/rust/issues/87184
Our CTFE test suite still seems to pass. However, we should probably crater this, and I want to do some tests with Miri as well.
bors [Mon, 2 Aug 2021 08:18:11 +0000 (08:18 +0000)]
Auto merge of #87297 - ZuseZ4:new_build_flags, r=Mark-Simulacrum
add two new build flags to build clang and enable llvm plugins
Based on the discussion here: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Add.20configure.20flag.20to.20build.20clang/near/246439138
It allows building clang (which already is part of the llvm-project) based on the same llvm version which we use to build rustc.
It also allows enabling llvm's plugin interface, which is required for https://enzyme.mit.edu/.
There is no further integration beside of this basic build support.
bors [Mon, 2 Aug 2021 05:49:17 +0000 (05:49 +0000)]
Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
Yuki Okushi [Mon, 2 Aug 2021 02:03:30 +0000 (11:03 +0900)]
Rollup merge of #87644 - Flying-Toast:vec-remove-note, r=the8472
Recommend `swap_remove` in `Vec::remove` docs
I was able to increase the performance (by 20%!) of my project by changing a `Vec::remove` call to `Vec::swap_remove` in a hot function. I think we should explicitly put a note in the Vec::remove docs to guide people in the right direction so they don't make a similar oversight.
Yuki Okushi [Mon, 2 Aug 2021 02:03:28 +0000 (11:03 +0900)]
Rollup merge of #87629 - steffahn:consistent_adapter_spelling, r=m-ou-se
Consistent spelling of "adapter" in the standard library
Change all occurrences of "(A|a)daptor" to "(A|a)dapter".
The spelling “adapter” seems to be significantly more common both in general in the English language and also in the `rust` repository and standard library. I don’t like the inconsistency that’s currently found on pages like https://doc.rust-lang.org/std/iter/trait.Iterator.html. Note however that the Rust book consistently uses the spelling “iterator adaptor”.
Related discussion [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/adapter.20.2F.20adaptor) ([in the archive](https://zulip-archive.rust-lang.org/219381tlibs/60284adapteradaptor.html)).
Yuki Okushi [Mon, 2 Aug 2021 02:03:26 +0000 (11:03 +0900)]
Rollup merge of #87504 - ehuss:update-mdbook, r=Mark-Simulacrum
Update mdbook.
Just a few minor changes. The changelog may be found at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md, for changes from 0.4.8 to 0.4.11.
Yuki Okushi [Mon, 2 Aug 2021 02:03:24 +0000 (11:03 +0900)]
Rollup merge of #87468 - calebcartwright:update-rustfmt, r=Mark-Simulacrum
Update rustfmt
Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity, but going forward will try to get on the same recurring cadence that clippy follows
Yuki Okushi [Mon, 2 Aug 2021 02:03:23 +0000 (11:03 +0900)]
Rollup merge of #87282 - pietroalbini:refactor-extended, r=Mark-Simulacrum
Ensure `./x.py dist` adheres to `build.tools`
According to `config.toml.example`, the way to produce dist artifacts for both the compiler and a *subset* of tools would be to enable the extended build and manually specify the list of tools to build:
This works as expected for `./x.py build` and `./x.py install`, but *not* for `./x.py dist`. Before this PR `./x.py dist` simply ignored the contents of `build.tools`, building just rustc/rustdoc if `build.extended = false` and all of the tools otherwise. This PR does two things:
* Changes `./x.py dist extended` to only build the tools defined in `build.tools`, if `build.tools` is not empty. The rest of the extended step was refactored to simplify the code.
* Changes how dist jobs for tools are gated: instead of `assert!(builder.config.extended)` to prevent tools from being built with `build.extended = false`, tools are simply built by default depending on `build.extended` and `build.tools`. This also enables to **explicitly** dist tools even with `build.extended = false`.
Yuki Okushi [Mon, 2 Aug 2021 02:03:22 +0000 (11:03 +0900)]
Rollup merge of #86936 - CDirkx:ipv6-multicast, r=JohnTitor
Add documentation for `Ipv6MulticastScope`
Adds basic documentation to the unstable `Ipv6MulticastScope`, as well as marking it `#[non_exhaustive]` because future IETF RFCs may introduce additional scopes. The documentation mentions this in a section "Stability Guarantees":
> /// Not all possible values for a multicast scope have been assigned.
/// Future RFCs may introduce new scopes, which will be added as variants to this enum;
/// because of this the enum is marked as `#[non_exhaustive]`.
Yuki Okushi [Mon, 2 Aug 2021 02:03:21 +0000 (11:03 +0900)]
Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last, r=m-ou-se
Partially stabilize `const_slice_first_last`
This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of.
Yuki Okushi [Mon, 2 Aug 2021 02:03:20 +0000 (11:03 +0900)]
Rollup merge of #86509 - CDirkx:os_str, r=m-ou-se
Move `os_str_bytes` to `sys::unix`
Followup to #84967, with `OsStrExt` and `OsStringExt` moved out of `sys_common`, there is no reason anymore for `os_str_bytes` to live in `sys_common` and not in sys. This pr moves it to the location `sys::unix::os_str` and reuses the code on other platforms via `#[path]` (as is common in `sys`) instead of importing.
Yuki Okushi [Mon, 2 Aug 2021 02:03:19 +0000 (11:03 +0900)]
Rollup merge of #86439 - CDirkx:ip-protocol-assignment, r=m-ou-se
Remove `Ipv4Addr::is_ietf_protocol_assignment`
This PR removes the unstable method `Ipv4Addr::is_ietf_protocol_assignment`, as I suggested in https://github.com/rust-lang/rust/issues/85612#issuecomment-847863404. The method was added in #60145, as far as I can tell primarily for the implementation of `Ipv4Addr::is_global` (addresses reserved for IETF protocol assignment are not globally reachable unless otherwise specified).
The method was added in 2019, but I haven't been able to find any open-source code using this method so far. I'm also having a hard time coming up with a usecase for specifically this method; knowing that an address is reserved for future protocols doesn't allow you to do much with it, especially since now some of those addresses are indeed assigned to a protocol and have their own behaviour (and might even be defined to be globally reachable, so if that is what you care about it is always more accurate to call `!is_global()`, instead of `is_ietf_protocol_assignment()`).
Because of these reasons, I propose removing the method (or alternatively make it a private helper for `is_global`) and also not introduce `Ipv6Addr::is_ietf_protocol_assignment` and `IpAddr::is_ietf_protocol_assignment` in the future.
Yuki Okushi [Mon, 2 Aug 2021 02:03:15 +0000 (11:03 +0900)]
Rollup merge of #86183 - inquisitivecrystal:env-nul, r=m-ou-se
Change environment variable getters to error recoverably
This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value.
On some platforms, it is invalid for environment variable names to contain `'\0'` or `'='`, or for their values to contain `'\0'`. Currently, the standard library panics when manipulating environment variables with names or values that violate these invariants. However, this behavior doesn't make a lot of sense, at least in the case of getters. If the environment variable is missing, the standard library just returns an error value, rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus, this PR changes the functions to error recoverably in this case as well.
If desired, I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them, I'm happy to implement the changes.
This fixes #86082, an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future.
bors [Mon, 2 Aug 2021 00:13:40 +0000 (00:13 +0000)]
Auto merge of #85272 - ChayimFriedman2:matches-leading-pipe, r=m-ou-se
Allow leading pipe in `matches!()` patterns.
This is allowed in `match` statement, and stated in https://internals.rust-lang.org/t/leading-pipe-in-core-matches/14699/2 that it should be allowed in these macros too.
bors [Sun, 1 Aug 2021 21:45:30 +0000 (21:45 +0000)]
Auto merge of #86031 - ssomers:btree_lazy_iterator, r=Mark-Simulacrum
BTree: lazily locate leaves in rangeless iterators
BTree iterators always locate both the first and last leaf edge and often only need either one, i.e., whenever they are traversed in a single direction, like in for-loops and in the common use of `iter().next()` or `iter().next_back()` to retrieve the first or last key/value-pair (#62924). It's fairly easy to avoid because the iterators with this disadvantage already are quite separate from other iterators.
bors [Sun, 1 Aug 2021 16:45:47 +0000 (16:45 +0000)]
Auto merge of #81825 - voidc:pidfd, r=joshtriplett
Add Linux-specific pidfd process extensions (take 2)
Continuation of #77168.
I addressed the following concerns from the original PR:
- make `CommandExt` and `ChildExt` sealed traits
- wrap file descriptors in `PidFd` struct representing ownership over the fd
- add `take_pidfd` to take the fd out of `Child`
- close fd when dropped
Dominik Stolz [Thu, 25 Mar 2021 21:46:37 +0000 (22:46 +0100)]
Do not call getpid wrapper after fork in tests
The test calls libc::getpid() in the pre_exec hook and asserts that the returned value is different from the PID of the parent.
However, libc::getpid() returns the wrong value.
Before version 2.25, glibc caches the PID of the current process with the goal of avoiding additional syscalls.
The cached value is only updated when the wrapper functions for fork or clone are called.
In PR #81825 we switch to directly using the clone3 syscall.
Thus, the cache is not updated and getpid returns the PID of the parent.
source: https://man7.org/linux/man-pages/man2/getpid.2.html#NOTES
Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object, and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind.
fn main() {
let thing: library::Thing = ...;
let _ = std::panic::catch_unwind(|| { let _ = thing; }); // does not work :(
}
```
See https://github.com/dtolnay/colorous/blob/a4131708e2f05d2377964981896ff62dbc9b027b/src/gradient.rs#L7-L15 for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller, as the `feature = "std"` would become non-additive in that case.
What happens without the UnwindSafe constraints:
```rust
fn main() {
let gradient = colorous::VIRIDIS;
let _ = std::panic::catch_unwind(|| { let _ = gradient; });
}
```
```console
error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
--> src/main.rs:3:13
|
3 | let _ = std::panic::catch_unwind(|| { let _ = gradient; });
| ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
|
::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40
|
430 | pub fn catch_unwind<F: FnOnce() -> R + UnwindSafe, R>(f: F) -> Result<R> {
| ---------- required by this bound in `catch_unwind`
|
= help: within `Gradient`, the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
= note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
= note: required because it appears within the type `Gradient`
= note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient`
= note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]`
```
bors [Sun, 1 Aug 2021 00:12:18 +0000 (00:12 +0000)]
Auto merge of #85782 - badboy:build-ios-sim-target, r=Mark-Simulacrum
Build aarch64-apple-ios-sim as part of the full macOS build
Part of the [MCP 428](https://github.com/rust-lang/compiler-team/issues/428) to promote this target to Tier 2.
This adds the aarch64-apple-ios-sim target as a tier 2 target, currently cross-compiled from our x86_64 apple builders. The compiler team has approved the addition per the MCP noted above, and the infrastructure team has not raised concerns with this addition at this time (as the CI time impact is expected to be minimal; this is only building std).
Auto merge of #87662 - FabianWolff:rb-string, r=estebank
Suggest `br` if the unknown string prefix `rb` is found
Currently, for the following code:
```rust
fn main() {
rb"abc";
}
```
we issue the following suggestion:
```
help: consider inserting whitespace here
|
2 | rb "abc";
| --
```
With my changes (only in edition 2021, where unknown prefixes became an error), I get:
```
help: use `br` for a raw byte string
|
2 | br"abc";
| ^^
```
Auto merge of #86264 - crlf0710:trait_upcasting_part1, r=nikomatsakis
Trait upcasting coercion (part1)
This revives the first part of earlier PR #60900 .
It's not very clear to me which parts of that pr was design decisions, so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details.
This is the first part, it adds feature gates, adds feature gates tests, and implemented the unsize conversion part.
(I hope i have dealt with the `ExistentialTraitRef` values correctly...)
The next part will be implementing the pointer casting.
Auto merge of #87387 - the8472:slice-iter-advance_by, r=scottmcm
Implement advance_by, advance_back_by for slice::{Iter, IterMut}
Part of #77404.
Picking up where #77633 was closed.
I have addressed https://github.com/rust-lang/rust/pull/77633#issuecomment-771842599 by restoring `nth` and `nth_back`. So according to that comment this should already be r=m-ou-se, but it has been sitting for a while.
Auto merge of #87640 - JohnTitor:rollup-yq24nq5, r=JohnTitor
Rollup of 9 pull requests
Successful merges:
- #86072 (Cross compiling rustc_llvm on Darwin requires zlib.)
- #87385 (Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default)
- #87547 (Add missing examples for NonNull)
- #87557 (Fix issue with autofix for ambiguous associated function from Rust 2021 prelude when struct is generic)
- #87559 (Tweak borrowing suggestion in `for` loop)
- #87596 (Add warning when whitespace is not skipped after an escaped newline)
- #87606 (Add some TAIT-related regression tests)
- #87609 (Add docs about performance and `Iterator::map` to `[T; N]::map`)
- #87616 (Fix missing word in rustdoc book)
My *guess* is that this gets the attention it gets because in JavaScript
(and potentially other languages), a `map` function on arrays is very
commonly used since in those languages, arrays basically take the role
of Rust's iterator. I considered explicitly naming JavaScript in the
first paragraph I added, but I couldn't find precedence of mentioning
other languages in standard library doc, so I didn't add it.
When array::map was stabilized, we still wanted to add docs, but that
somehow did not happen in time. So here we are. Not sure if this sounds
crazy but maybe it is worth considering beta backporting this? Only if
it's not a lot of work, of course! But yeah, stabilized array::map is
already in beta and if this problem is really as big as it sometimes seems,
might be worth having the docs in place when 1.55 is released.
CC ``@CryZe``
r? ``@m-ou-se`` (since you were involved in that discussion and the stabilization)
Rollup merge of #87596 - jesyspa:issue-87318-hidden-whitespace, r=estebank
Add warning when whitespace is not skipped after an escaped newline
Fixes issue #87318, also simplifies issue #87319.
* Add support to the lexer to emit warnings as well as errors.
* Emit a warning when a string literal contains an escaped newline, but when (some of) the whitespace on the next line is not skipped due to it being non-ASCII.
Rollup merge of #87557 - rylev:fix-invalid-prelude-collision-error, r=nikomatsakis
Fix issue with autofix for ambiguous associated function from Rust 2021 prelude when struct is generic
Fixes #86940
The test cases and associated issue should make it clear what specifically this is meant to fix. The fix is slightly hacky in that we check against the literal source code of the call site for the presence of `<` in order to determine if the user has included the generics for the struct (meaning we don't need to include them for them).
Rollup merge of #87385 - Aaron1011:final-enable-semi, r=petrochenkov
Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default
This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default.
To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon.
In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
Auto merge of #85971 - FabianWolff:issue-85586, r=davidtwco
Use more precise span for E0282 in cast expressions
This pull request fixes #85586. The example code given there:
```rust
fn main() {
let a = [1, 2, 3].iter().sum();
let b = (a + 1) as usize;
}
```
currently produces
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^^^^^^^^^^ cannot infer type
|
= note: type must be known at this point
error: aborting due to previous error
```
even though the type of the entire cast expression quite clearly should be `usize`. The error is in the cast's left-hand side, which is made explicit by the changes in this PR:
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^ cannot infer type
|
= note: type must be known at this point
Auto merge of #87237 - jonas-schievink:const-for-and-try, r=oli-obk
Add feature gates for `for` and `?` in consts
These operations seems *relatively* straightforward to support, and only seem to be blocked on `impl const Trait`.
I have included a working test for `const_try`, but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method, so I didn't do that.
(both features still need tracking issues before this is merged)
Auto merge of #87615 - JohnTitor:rollup-t5jpmrg, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #87052 (Optimize fmt::PadAdapter::wrap)
- #87522 (Fix assert in diy_float)
- #87553 (Fix typo in rustc_driver::version)
- #87554 (2229: Discr should be read when PatKind is Range)
- #87564 (min_type_alias_impl_trait is going to be removed in 1.56)
- #87574 (Update the examples in `String` and `VecDeque::retain`)
- #87583 (Refactor compression cache in v0 symbol mangler)
- #87585 (Add missing links for core::char types)
- #87594 (fs File get_path procfs usage for netbsd same as linux.)
- #87602 ([backtraces]: look for the `begin` symbol only after seeing `end`)
Notice that `__rust_begin_short_backtrace` appears on frame 11 before
`__rust_end_short_backtrace` on frame 12. This is because in typical
release binaries without debug symbols, dbghelp.dll, which we use to walk
and symbolize the stack, does not know where CGU internal functions
start or end and so the closure invoked by `__rust_end_short_backtrace`
is incorrectly described as `__rust_begin_short_backtrace` because it
happens to be near that symbol.
While that can obviously change, this has been happening quite
consistently since #75048. Since this is a very small change to the std
and the change makes sense by itself, I think this is worth doing.
This doesn't completely resolve the situation for release binaries on
Windows, since without debug symbols, the stack printed can still show
incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
does slightly improve the situation in that you see the same backtrace
you would see with `RUST_BACKTRACE=full` or in a debugger (without the
uninteresting bits at the top and bottom).
Rollup merge of #87583 - tmiasko:compression-cache, r=wesleywiser
Refactor compression cache in v0 symbol mangler
* Remove redundant option around compression caches (they are always present).
* Flatten compression caches into symbol mangler to avoid dynamic memory allocation.
* Implement printer for `&mut SymbolMangler` instead of `SymbolMangler` to avoid passing now slightly larger symbol mangler by value.
Rollup merge of #87574 - cuviper:retain-examples, r=joshtriplett
Update the examples in `String` and `VecDeque::retain`
The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.
Rollup merge of #87564 - spastorino:adjust-min-tait-removed-version, r=jackh726
min_type_alias_impl_trait is going to be removed in 1.56
#87501 removed `min_type_alias_impl_trait` but meanwhile that PR was approved in homu queue, a new beta was cut so we need to bump the version because it won't be removed in 1.55.
Rollup merge of #87052 - phlopsi:patch-1, r=jyn514
Optimize fmt::PadAdapter::wrap
After adding the first `write!` usage to my project and printing the result to the console, I noticed, that my binary contains the strings "called `Option::unwrap()` on a `None` value`" and more importantly "C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs", with my release build being configured as follows:
```
[profile.release]
panic = "abort"
codegen-units = 1
strip = "symbols" # the important bit
lto = true
```
I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`.
Aside from me suspecting this function to be the culprit, the replaced code performs the same operation as `Option::insert`, but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore, it makes sense to me to use the more optimized version, instead.
As I don't change any semantics, I hope a simple pull request suffices.
Mir borrowck does not generate lifetime variables for 'static lifetimes during opaque type resolution
Fixes #87455
This situation was unreachable before #87287 as we used to just grab the resolved opaque type from typeck and replaced all regions with new inference vars. After #87287 we let the `InferCx` in mir borrowck figure out the opaque type all by itself (which it already did before, but it only used the result to sanity check with the typeck result).
projects / rust.git / log