Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 11 pull requests #62923

Closed
wants to merge 36 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jul 24, 2019

Successful merges:

Failed merges:

r? @ghost

varkor and others added 30 commits July 1, 2019 00:52
Co-Authored-By: Mazdak Farrokhzad <[email protected]>
Co-Authored-By: Mazdak Farrokhzad <[email protected]>
Co-Authored-By: Mazdak Farrokhzad <[email protected]>
Usages still appear in cloudabi tests and in the reentrant mutex implementation
Remove uses of mem::uninitialized, which is now deprecated
…inhabited-subst, r=oli-obk

Take substs into account in `conservative_is_privately_uninhabited`
Add joining slices of slices with a slice separator, not just a single item

rust-lang#27747 (comment)
> It's kinda annoying to be able to join strings with a str (which can have multiple chars), but joining a slice of slices, you can only join with a single element.

This turns out to be fixable, with some possible inference regressions.

# TL;DR

Related trait(s) are unstable and tracked at rust-lang#27747, but the `[T]::join` method that is being extended here is already stable.

Example use of the new insta-stable functionality:

```rust
let nested: Vec<Vec<Foo>> = /* … */;
let separator: &[Foo] = /* … */;  // Previously: could only be a single &Foo
nested.join(separator)
```

Complete API affected by this PR, after changes:

```rust
impl<T> [T] {
    pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output
        where Self: Concat<Item>
    {
        Concat::concat(self)
    }
    pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output
        where Self: Join<Separator>
    {
        Join::join(self, sep)
    }
}

// The `Item` parameter is only useful for the the slice-of-slices impl.
pub trait Concat<Item: ?Sized> {
    type Output;
    fn concat(slice: &Self) -> Self::Output;
}

pub trait Join<Separator> {
    type Output;
    fn join(slice: &Self, sep: Separator) -> Self::Output;
}

impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] {
    type Output = Vec<T>;
}

impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] {
    type Output = Vec<T>;
}

// New functionality here!
impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] {
    type Output = Vec<T>;
}

impl<S: Borrow<str>> Concat<str> for [S] {
    type Output = String;
}

impl<S: Borrow<str>> Join<&'_ str> for [S] {
    type Output = String;
}
```

# Details

After rust-lang#62403 but before this PR, the API is:

```rust
impl<T> [T] {
    pub fn concat<Separator: ?Sized>(&self) -> T::Output
        where T: SliceConcat<Separator>
    {
        SliceConcat::concat(self)
    }

    pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output
        where T: SliceConcat<Separator>
    {
        SliceConcat::join(self, sep)
    }
}

pub trait SliceConcat<Separator: ?Sized>: Sized {
    type Output;
    fn concat(slice: &[Self]) -> Self::Output;
    fn join(slice: &[Self], sep: &Separator) -> Self::Output;
}

impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V {
    type Output = Vec<T>;
}

impl<S: Borrow<str>> SliceConcat<str> for S {
    type Output = String;
}
```

By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value.

In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great.

The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous.

Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore:

```rust
error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates
  --> src/liballoc/slice.rs:608:6
    |
608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] {
    |      ^ unconstrained type parameter
```

This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`.

This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it.

The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls.

In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes.

# Joining strings with `char`

For symmetry I also tried adding this impl (because why not):

```rust
impl<S: Borrow<str>> Join<char> for [S] {
    type Output = String;
}
```

This immediately caused an inference regression in a dependency of rustc:

```rust
error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied
   --> /home/simon/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37
    |
595 |             row.push_str(&desc_rows.join(&desc_sep));
    |                                     ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String`
    |
    = help: the following implementations were found:
              <std::string::String as std::borrow::Borrow<str>>
    = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]`
```

In the context of this code, two facts are known:

* `desc_rows` is a `Vec<String>`
* `desc_sep` is a `String`

Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`.

With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution.

I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))`

The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.
… r=RalfJung

Remove uses of mem::uninitialized from std::sys::cloudabi

Addresses rust-lang#62397 for std::sys::cloudabi, excluding the tests within cloudabi, which will be a separate PR
Add riscv32i-unknown-none-elf target

This target is likely to be useful for constrained FPGA soft-cores, such as picorv32 and HeavyX.
…_compiler_messages_p16, r=Centril

Normalize use of backticks in compiler messages for doc

rust-lang#60532
…_compiler_messages_p17, r=alexreg

normalize use of backticks for compiler messages in remaining modules

rust-lang#60532
@Centril
Copy link
Contributor Author

Centril commented Jul 24, 2019

@bors r+ p=11 rollup=never

@bors
Copy link
Contributor

bors commented Jul 24, 2019

📌 Commit 69bc410 has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 24, 2019
@bors
Copy link
Contributor

bors commented Jul 24, 2019

⌛ Testing commit 69bc410 with merge c432cffb34ec4c425f408e1ef9b96886dc1fcc32...

@bors
Copy link
Contributor

bors commented Jul 24, 2019

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 24, 2019
@Centril
Copy link
Contributor Author

Centril commented Jul 24, 2019

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2019
@bors
Copy link
Contributor

bors commented Jul 24, 2019

⌛ Testing commit 69bc410 with merge 486833d...

bors added a commit that referenced this pull request Jul 24, 2019
Rollup of 11 pull requests

Successful merges:

 - #62261 (Take substs into account in `conservative_is_privately_uninhabited`)
 - #62528 (Add joining slices of slices with a slice separator, not just a single item)
 - #62738 (Remove uses of mem::uninitialized from std::sys::cloudabi)
 - #62784 (Add riscv32i-unknown-none-elf target)
 - #62808 (Revert "Disable stack probing for gnux32.")
 - #62814 (add support for hexagon-unknown-linux-musl)
 - #62822 (Improve some pointer-related documentation)
 - #62890 (Normalize use of backticks in compiler messages for libsyntax/*)
 - #62901 (cleanup: Remove `extern crate serialize as rustc_serialize`s)
 - #62905 (Normalize use of backticks in compiler messages for doc)
 - #62908 (normalize use of backticks for compiler messages in remaining modules)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jul 24, 2019

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 24, 2019
@Centril
Copy link
Contributor Author

Centril commented Jul 24, 2019

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2019
@bors
Copy link
Contributor

bors commented Jul 24, 2019

⌛ Testing commit 69bc410 with merge 76da8ad20b36ebfee2046921c28826a2e4cffa81...

@bors
Copy link
Contributor

bors commented Jul 24, 2019

💔 Test failed - checks-azure

@rust-highfive
Copy link
Collaborator

Your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-07-24T09:58:34.0716998Z do so (now or later) by using -b with the checkout command again. Example:
2019-07-24T09:58:34.0717053Z 
2019-07-24T09:58:34.0717308Z   git checkout -b <new-branch-name>
2019-07-24T09:58:34.0717557Z 
2019-07-24T09:58:34.0717899Z HEAD is now at 76da8ad20 Auto merge of #62923 - Centril:rollup-53i3am3, r=Centril
2019-07-24T09:58:34.0858953Z ##[section]Starting: Collect CPU-usage statistics in the background
2019-07-24T09:58:34.0861989Z ==============================================================================
2019-07-24T09:58:34.0862082Z Task         : Bash
2019-07-24T09:58:34.0862157Z Description  : Run a Bash script on macOS, Linux, or Windows
---
2019-07-24T10:01:44.9020940Z Script contents:
2019-07-24T10:01:44.9021701Z aws s3 cp --acl public-read cpu-usage.csv s3://$DEPLOY_BUCKET/rustc-builds/$BUILD_SOURCEVERSION/cpu-$SYSTEM_JOBNAME.csv
2019-07-24T10:01:44.9042567Z ========================== Starting Command Output ===========================
2019-07-24T10:01:44.9061190Z [command]/bin/bash --noprofile --norc /home/vsts/work/_temp/2ffe1be6-ce13-482b-a8d8-527a86b73b29.sh
2019-07-24T10:01:44.9153843Z /home/vsts/work/_temp/2ffe1be6-ce13-482b-a8d8-527a86b73b29.sh: line 1: aws: command not found
2019-07-24T10:01:44.9188811Z ##[error]Bash exited with code '127'.
2019-07-24T10:01:44.9219057Z ##[section]Starting: Checkout
2019-07-24T10:01:44.9220961Z ==============================================================================
2019-07-24T10:01:44.9221050Z Task         : Get sources
2019-07-24T10:01:44.9221168Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 24, 2019
@Centril Centril closed this Jul 24, 2019
@Centril Centril deleted the rollup-53i3am3 branch July 24, 2019 14:14
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants