bors [Tue, 3 Aug 2021 02:18:24 +0000 (02:18 +0000)]
Auto merge of #86335 - CDirkx:ipv4-in-ipv6, r=dtolnay
Commit to not supporting IPv4-in-IPv6 addresses
Stabilization of the `ip` feature has for a long time been blocked on the question of whether Rust should support handling "IPv4-in-IPv6" addresses: should the various `Ipv6Address` property methods take IPv4-mapped or IPv4-compatible addresses into account. See also the IPv4-in-IPv6 Address Support issue #85609 and #69772 which originally asked the question.
# Overview
In the recent PR #85655 I proposed changing `is_loopback` to take IPv4-mapped addresses into account, so `::ffff:127.0.0.1` would be recognized as a looback address. However, due to the points that came up in that PR, I alternatively propose the following: Keeping the current behaviour and commit to not assigning any special meaning for IPv4-in-IPv6 addresses, other than what the standards prescribe. This would apply to the stable method `is_loopback`, but also to currently unstable methods like `is_global` and `is_documentation` and any future methods. This is implemented in this PR as a change in documentation, specifically the following section:
> Both types of addresses are not assigned any special meaning by this implementation, other than what the relevant standards prescribe. This means that an address like `::ffff:127.0.0.1`, while representing an IPv4 loopback address, is not itself an IPv6 loopback address; only `::1` is. To handle these so called "IPv4-in-IPv6" addresses, they have to first be converted to their canonical IPv4 address.
# Discussion
In the discussion for or against supporting IPv4-in-IPv6 addresses the question what would be least surprising for users of other languages has come up several times. At first it seemed most big other languages supported IPv4-in-IPv6 addresses (or at least considered `::ffff:127.0.0.1` a loopback address). However after further investigation it appears that supporting IPv4-in-IPv6 addresses comes down to how a language represents addresses. .Net and Go do not have a separate type for IPv4 or IPv6 addresses, and do consider `::ffff:127.0.0.1` a loopback address. Java and Python, which do have separate types, do not consider `::ffff:127.0.0.1` a loopback address. Seeing as Rust has the separate `Ipv6Addr` type, it would make sense to also not support IPv4-in-IPv6 addresses. Note that this focuses on IPv4-mapped addresses, no other language handles IPv4-compatible addresses.
Another issue that was raised is how useful supporting these IPv4-in-IPv6 addresses would be in practice. Again with the example of `::ffff:127.0.0.1`, considering it a loopback address isn't too useful as to use it with most of the socket APIs it has to be converted to an IPv4 address anyway. From that perspective it would be better to instead provide better ways for doing this conversion like stabilizing `to_ipv4_mapped` or introducing a `to_canonical` method.
A point in favour of not supporting IPv4-in-IPv6 addresses is that that is the behaviour Rust has always had, and that supporting it would require changing already stable functions like `is_loopback`. This also keeps the documentation of these functions simpler, as we only have to refer to the relevant definitions in the IPv6 specification.
# Decision
To make progress on the `ip` feature, a decision needs to be made on whether or not to support IPv4-in-IPv6 addresses.
There are several options:
- Keep the current implementation and commit to never supporting IPv4-in-IPv6 addresses (accept this PR).
- Support IPv4-in-IPv6 addresses in some/all `IPv6Addr` methods (accept PR #85655).
- Keep the current implementation and but not commit to anything yet (reject both this PR and PR #85655), this entire issue will however come up again in the stabilization of several methods under the `ip` feature.
There are more options, like supporting IPv4-in-IPv6 addresses in `IpAddr` methods instead, but to my knowledge those haven't been seriously argued for by anyone.
There is currently an FCP ongoing on PR #85655. I would ask the libs team for an alternative FCP on this PR as well, which if completed means the rejection of PR #85655, and the decision to commit to not supporting IPv4-in-IPv6 addresses.
If anyone feels there is not enough evidence yet to make the decision for or against supporting IPv4-in-IPv6 addresses, let me know and I'll do whatever I can to resolve it.
bors [Mon, 2 Aug 2021 15:54:11 +0000 (15:54 +0000)]
Auto merge of #87698 - camsteffen:rollup-yvjfc26, r=camsteffen
Rollup of 6 pull requests
Successful merges:
- #86176 (Implement a `explicit_generic_args_with_impl_trait` feature gate)
- #87654 (Add documentation for the order of Option and Result)
- #87659 (Fix invalid suggestions for non-ASCII characters in byte constants)
- #87673 (Tweak opaque type mismatch error)
- #87687 (Inline some macros)
- #87690 (Add missing "allocated object" doc link to `<*mut T>::add`)
Cameron Steffen [Mon, 2 Aug 2021 14:36:55 +0000 (09:36 -0500)]
Rollup merge of #87690 - sharnoff:mut-ptr-allocated-obj-link, r=Mark-Simulacrum
Add missing "allocated object" doc link to `<*mut T>::add`
The portion of the documentation expecting the link was already there, but it was rendered as "[allocated object]". The added reference is just copied from the documentation for `<*const T>::add`.
Cameron Steffen [Mon, 2 Aug 2021 14:36:49 +0000 (09:36 -0500)]
Rollup merge of #86176 - nbdd0121:explicit-generic-args, r=jackh726
Implement a `explicit_generic_args_with_impl_trait` feature gate
Implements #83701
When this gate is enabled, explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait`
So code like this will be accepted:
```rust
#![feature(explicit_generic_args_with_impl_trait)]
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.
Gary Guo [Wed, 9 Jun 2021 19:56:41 +0000 (20:56 +0100)]
Implement a `explicit_generic_args_with_impl_trait` feature gate
When this gate is enabled, explicit generic arguments can be specified even
if `impl Trait` is used in argument position. Generic arguments can only be
specified for explicit generic parameters but not for the synthetic type
parameters from `impl Trait`
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.
projects / rust.git / log