Skip to content

Make signature of Path::strip_prefix accept non-references #48989

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

Merged
merged 2 commits into from
Apr 24, 2018

Conversation

ExpHP
Copy link
Contributor

@ExpHP ExpHP commented Mar 13, 2018

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.

BREAKING CHANGE:
This has the potential to cause regressions in type inference.
@rust-highfive
Copy link
Contributor

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 13, 2018
/// ```
#[stable(since = "1.7.0", feature = "path_strip_prefix")]
pub fn strip_prefix<'a, P: ?Sized>(&'a self, base: &'a P)
-> Result<&'a Path, StripPrefixError>
pub fn strip_prefix<'a, P>(&'a self, base: P)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the 'a lifetime can now be elided.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, thanks for catching this!

where P: AsRef<Path>
{
self._strip_prefix(base.as_ref())
}

fn _strip_prefix<'a>(&'a self, base: &'a Path)
fn _strip_prefix<'a>(&'a self, base: &Path)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I believe 'a can be elided.

@dtolnay dtolnay added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Mar 17, 2018
@dtolnay
Copy link
Member

dtolnay commented Mar 17, 2018

I would be on board with attempting to land this. The original signature is indeed strange, and the way strip_prefix is typically used I would expect nothing to break.

  impl Path {
-     pub fn strip_prefix<'a, P: ?Sized>(&'a self, base: &'a P) -> Result<&'a Path, StripPrefixError>
+     pub fn strip_prefix<P>(&self, base: P) -> Result<&Path, StripPrefixError>
          where P: AsRef<Path>;
  }

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Mar 17, 2018

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 17, 2018
@SimonSapin
Copy link
Contributor

I'm having a hard time imagining such a scenario in real code.

This sounds like “let’s do a crater run”. What’s the process for that?

@SimonSapin
Copy link
Contributor

@rfcbot concern crater

@shepmaster shepmaster added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 23, 2018
@pietroalbini pietroalbini added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Apr 16, 2018
@pietroalbini
Copy link
Member

Added this to the crater queue.

@Mark-Simulacrum
Copy link
Member

@bors try

@bors
Copy link
Collaborator

bors commented Apr 18, 2018

⌛ Trying commit 7cbc93b with merge df2fbb30d918e67865a57dbf24fd35a01fdc5d39...

@bors
Copy link
Collaborator

bors commented Apr 19, 2018

☀️ Test successful - status-travis
State: approved= try=True

@Mark-Simulacrum
Copy link
Member

Crater run started, ETA is ~3 days.

@Mark-Simulacrum
Copy link
Member

Crater results all look like spurious failures. http://cargobomb-reports.s3.amazonaws.com/pr-48989/index.html

@dtolnay
Copy link
Member

dtolnay commented Apr 24, 2018

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 24, 2018

📌 Commit 7cbc93b has been approved by dtolnay

@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-crater Status: Waiting on a crater run to be completed. labels Apr 24, 2018
@bors
Copy link
Collaborator

bors commented Apr 24, 2018

⌛ Testing commit 7cbc93b with merge a1286f6...

bors added a commit that referenced this pull request Apr 24, 2018
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.
@bors
Copy link
Collaborator

bors commented Apr 24, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: dtolnay
Pushing a1286f6 to master...

@bors bors merged commit 7cbc93b into rust-lang:master Apr 24, 2018
@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Apr 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants