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

Partial implementation for UFCS trait-less associated paths. #22172

Merged
merged 27 commits into from
Feb 24, 2015

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Feb 11, 2015

Adds <module::Type>::method support and makes module::Type::method a shorthand for it.
This is most of #16293, except that chaining multiple associated types is not yet supported.
It also fixes #22563 as impls are no longer treated as modules in resolve.

Unfortunately, this is still a [breaking-change]:

  • If you used a global path to a primitive type, i.e. ::bool, ::i32 etc. - that was a bug I had to fix.
    Solution: remove the leading ::.
  • If you passed explicit impl-side type parameters to an inherent method, e.g.:
struct Foo<T>(T);
impl<A, B> Foo<(A, B)> {
    fn pair(a: A, b: B) -> Foo<(A, B)> { Foo((a, b)) }
}
Foo::<A, B>::pair(a, b)
// Now that is sugar for:
<Foo<A, B>>::pair(a, b)
// Which isn't valid because `Foo` has only one type parameter.
// Solution: replace with:
Foo::<(A, B)>::pair(a, b)
// And, if possible, remove the explicit type param entirely:
Foo::pair(a, b)

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@nikomatsakis
Copy link
Contributor

very cool, I will read.

@nikomatsakis
Copy link
Contributor

@eddyb sorry for being slow. I spent some time reading into this two days back but yesterday got very busy. I expect to finish up today.

@nikomatsakis
Copy link
Contributor

First off, some nits here: nikomatsakis@b6461f0

@nikomatsakis
Copy link
Contributor

r+, awesome! But I did have some conditions and comments :)

Conditions:

  • Nits at nikomatsakis@b6461f0
  • More new tests! Surely there are new constructions to test here? Some thoughts:
    • the fact that inherent takes precedence over trait
    • distinction between Trait::method and <Trait>::method
    • inherent impls are, I guess, extensively tested already, but there are probably some variations on them that you enable that didn't work right before, right?
    • can you rename const-polymorphic-paths to something like ufcs-trait-relative-paths or just anything that begins with ufcs? I'm pretty sure I'd never find it with the current name, and (iiuc) it tests more than just consts.
  • A comment or two about PartialDef and what the heck depth means (in resolve_path and friends) would be nice.

Comments/Questions:

I still feel like a reworking of resolve and the data structures around resolve (notably, Path and Def) could yield substantially cleaner code, but this seems to be overall a pretty reasonable approach.

One thing I noticed that stuck out at me: in resolve, if parsing a::b::c::d, it seems that you first try to parse the entire path, then you drop segments from the RHS one by one (so next try a::b::c, then a::b, etc) until you find a hit. This seems remarkably inefficient. I am assuming that this was the easiest way to shoehorn this work on top of resolve -- is there a deeper reason for this approach?

I also found the "suppress errors" flag a little bit suboptimal, compared to passing back an error as a result, but it's a relatively minor thing. In general I'd like to see resolution refactored into a "side-effect-free" lookup that returns errors / successful results, leaving it to the caller to decide what to do with those.

I was happy to see you integrated the lookup into probe.

@eddyb eddyb changed the title Desugar module::Type::method to <module::Type>::method. Partial implementation for UFCS trait-less associated paths. Feb 17, 2015
@eddyb eddyb force-pushed the almost-there branch 3 times, most recently from b7dd4cc to 43bac21 Compare February 17, 2015 17:29
@nikomatsakis
Copy link
Contributor

@eddyb ok, so I finished reviewing as of 43bac21. Let's call them concerns, for the most part -- more than nits, but certainly not blockers. Anyway, I'd appreciate clarification about the potential for ICEs etc. I'd like to have a change to look over the patch once you address them -- or tell me why I am wrong --- but promise to make it quick presuming major changes aren't needed.

@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2015

@bors r=nikomatsakis 7af58b8

@bors
Copy link
Contributor

bors commented Feb 19, 2015

⌛ Testing commit 7af58b8 with merge de86968...

@bors
Copy link
Contributor

bors commented Feb 19, 2015

💔 Test failed - auto-linux-64-x-android-t

@bors
Copy link
Contributor

bors commented Feb 19, 2015

💔 Test failed - auto-mac-32-opt

@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2015

@bors r=nikomatsakis 6e58a42

@bors
Copy link
Contributor

bors commented Feb 19, 2015

⌛ Testing commit 6e58a42 with merge bf9938f...

@bors
Copy link
Contributor

bors commented Feb 19, 2015

💔 Test failed - auto-mac-64-nopt-t

@eddyb
Copy link
Member Author

eddyb commented Feb 19, 2015

@bors r=nikomatsakis e979cf4

@eddyb
Copy link
Member Author

eddyb commented Feb 24, 2015

@bors r=nikomatsakis 0c6d1f3

@bors
Copy link
Contributor

bors commented Feb 24, 2015

⌛ Testing commit 0c6d1f3 with merge f33e2e2...

@bors
Copy link
Contributor

bors commented Feb 24, 2015

💔 Test failed - auto-win-32-nopt-t

@Manishearth
Copy link
Member

@bors: retry force

@Manishearth
Copy link
Member

@bors: force

@bors
Copy link
Contributor

bors commented Feb 24, 2015

⌛ Testing commit 0c6d1f3 with merge 695bde9...

@bors
Copy link
Contributor

bors commented Feb 24, 2015

⌛ Testing commit 0c6d1f3 with merge 0b975cb...

@bors
Copy link
Contributor

bors commented Feb 24, 2015

💔 Test failed - auto-win-32-nopt-t

@Manishearth
Copy link
Member

@bors: retry

@bors
Copy link
Contributor

bors commented Feb 24, 2015

⌛ Testing commit 0c6d1f3 with merge 0bd1565...

bors added a commit that referenced this pull request Feb 24, 2015
Adds `<module::Type>::method` support and makes `module::Type::method` a shorthand for it.
This is most of #16293, except that chaining multiple associated types is not yet supported.
It also fixes #22563 as `impl`s are no longer treated as modules in resolve.

Unfortunately, this is still a *[breaking-change]*:
* If you used a global path to a primitive type, i.e. `::bool`, `::i32` etc. - that was a bug I had to fix.
Solution: remove the leading `::`.
* If you passed explicit `impl`-side type parameters to an inherent method, e.g.:
```rust
struct Foo<T>(T);
impl<A, B> Foo<(A, B)> {
    fn pair(a: A, b: B) -> Foo<(A, B)> { Foo((a, b)) }
}
Foo::<A, B>::pair(a, b)
// Now that is sugar for:
<Foo<A, B>>::pair(a, b)
// Which isn't valid because `Foo` has only one type parameter.
// Solution: replace with:
Foo::<(A, B)>::pair(a, b)
// And, if possible, remove the explicit type param entirely:
Foo::pair(a, b)
```
* If you used the `QPath`-related `AstBuilder` methods @hugwijst added in #21943.
The methods still exist, but `QPath` was replaced by `QSelf`, with the actual path stored separately.
Solution: unpack the pair returned by `cx.qpath` to get the two arguments for `cx.expr_qpath`.
@bors bors merged commit 0c6d1f3 into rust-lang:master Feb 24, 2015
@eddyb eddyb deleted the almost-there branch February 24, 2015 20:52
SSheldon added a commit to SSheldon/rust-objc that referenced this pull request Feb 27, 2015
SSheldon added a commit to SSheldon/rust-objc-foundation that referenced this pull request Mar 23, 2015
SSheldon added a commit to SSheldon/rust-objc-id that referenced this pull request May 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't require impls next to structs
6 participants