Skip to content
New issue

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

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # 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