Android abstract unix domain sockets AddressKind correction
The prior check causes abstract unix domain sockets to return AddressKind::Unnamed instead of AddressKind::Abstract on Android.
Other than the immediately proceeding comment "macOS seems to return a len of 16 and a zeroed sun_path for unnamed addresses" the check as-implemented does not seem to have alternative explanation. I couldn't find an alternative explanation while stepping though git blame. I suspect the AddressKind::Unnamed nonzero check should instead be if macos, length 16, and zeroed array. @sfackler could you comment on this, the code as-is is the same from your initial addition of abstract uds support.
encourage descriptive issue titles
There are two sides to avoiding duplicate issues, searching for existing ones, and making sure existing ones can be searched for. This addresses the later.
r? @steveklabnik
don't see issue #0
The unstable-feature attribute requires an issue (neglecting it is
E0547), which gets used in the error messages. Unfortunately, there are
some cases where "0" is apparently used a placeholder where no issue
exists, directing the user to see the (nonexistent) issue #0. (It would
have been better to either let `issue` be optional—compare to how issue
is an `Option<u32>` in the feature-gate declarations in
libsyntax/feature-gate.rs—or actually require that an issue be created.)
Rather than endeavoring to change how `#[unstable]` works at this time
(given competing contributor and reviewer priorities), this simple patch
proposes the less-ambitious solution of just not adding the "(see
issue)" note when the number is zero.
Resolves#49983.
Add doc links to `std::os` extension traits
Addresses a small subset of #29367.
This adds documentation links to the original type for various OS-specific extension traits, and uses a common sentence for introducing such traits (which now consistently ends in a period).
Add Cell::update
This commit adds a new method `Cell::update`, which applies a function to the value inside the cell.
Previously discussed in: https://github.com/rust-lang/rfcs/issues/2171
### Motivation
Updating `Cell`s is currently a bit verbose. Here are several real examples (taken from rustc and crossbeam):
```rust
self.print_fuel.set(self.print_fuel.get() + 1);
self.diverges.set(self.diverges.get() | Diverges::Always);
let guard_count = self.guard_count.get();
self.guard_count.set(guard_count.checked_add(1).unwrap());
if guard_count == 0 {
// ...
}
```
With the addition of the new method `Cell::update`, this code can be simplified to:
```rust
self.print_fuel.update(|x| x + 1);
self.diverges.update(|x| x | Diverges::Always);
if self.guard_count.update(|x| x.checked_add(1).unwrap()) == 1 {
// ...
}
```
### Unresolved questions
1. Should we return the old value instead of the new value (like in `fetch_add` and `fetch_update`)?
2. Should the return type simply be `()`?
3. Naming: `update` vs `modify` vs `mutate` etc.
cc @SimonSapin
std: Child::kill() returns error if process has already exited
This patch makes it clear in std::process::Child::kill()'s API
documentation that an error is returned if the child process has
already cleanly exited. This is implied by the example, but not
called out explicitly.
Make signature of Path::strip_prefix accept non-references
I did this a while back but didn't submit a PR. Might as well see what happens.
Fixes#48390.
**Note: This has the potential to cause regressions in type inference.** However, in order for code to break, it would need to be relying on the signature to determine that a type is `&_`, while still being able to figure out what the `_` is. I'm having a hard time imagining such a scenario in real code.
This computes the transitive closure of traits that appear in the
environment and then appends their clauses. It needs some work, but
it's in the right direction.
Chalk wants to be able to pass these constraints around. Also, the
form we were using in our existing queries was not as general as we
are going to need.
Better error message when trying to write default impls
Previously, if you tried to write this (using the specialization
feature flag):
default impl PartialEq<MyType> {
...
}
The compiler would give you the mysterious warning "inherent impls
cannot be default". What it really means is that you're trying to
write an impl for a Structure or *Trait Object*, and that cannot
be "default". However, one of the ways to encounter this error
(as shown by the above example) is when you forget to write "for
MyType".
This PR adds a help message that reads "maybe missing a `for`
keyword?" This is useful, actionable advice that will help any user
identify their mistake, and doesn't get in the way or mislead any
user that really meant to use the "default" keyword for this weird
purpose. In particular, this help message will be useful for any
users who don't know the "inherent impl" terminology, and/or users
who forget that inherent impls CAN be written for traits (they apply
to the trait objects). Both of these are somewhat confusing, seldom-
used concepts; a one-line error message without any error number for
longer explanation is NOT the place to introduce these ideas.
I wasn't quite sure what grammar / wording to use. I'm open to suggestions. CC @rust-lang/docs (I hope I'm doing that notation right)
(Apparently not. :( )
