Reference type as associated value instead of generic #132

faern · 2017-11-24T19:35:15Z

Each CFFoo has exactly one CFFooRef and which one is defined by CFFoo, not by its user. Thus the type of reference can be an associated type instead of a generic.

As you can see this greatly simplifies things such as calling instance_of and from_CFType_pairs as well as using CFPropertyListSubClass. It basically removes one generic parameter from any method dealing with TCFTypes in some way.

This is a breaking change, so it would probably mean a 0.5.0 release if accepted. I don't know what your stance on breaking changes or version bumps is, so I don't know if you want this or not. But it would simplify the API, both here, but first and foremost in higher level crates using this.

This change is

faern · 2017-11-24T19:37:25Z

core-foundation/src/dictionary.rs

-        self.contains_key(key.as_concrete_TypeRef() as *const c_void)
+    pub fn contains_key2<K: TCFType>(&self, key: &K) -> bool {
+        let type_ref_ptr = &key.as_concrete_TypeRef() as *const _ as *const *const c_void;
+        self.contains_key(unsafe { *type_ref_ptr })


This implementation had to pay with a bit complexity for the reduced API complexity.

Basically, now I don't know that K::TypeRef is a *const _ any longer, so I can't just cast the pointer directly. Instead I have to take the pointer to the pointer and then cast that and lastly dereference.

I added a unit test to make sure I got it right.

faern · 2017-11-24T19:40:17Z

core-foundation/src/propertylist.rs

+            let ptr = &self.0 as *const _ as *const <T as TCFType>::TypeRef;
+            unsafe {
+                let reference: &<T as TCFType>::TypeRef = &*ptr;
+                Some(T::wrap_under_get_rule(mem::transmute_copy(reference)))


This implementation became uglier in order to get rid of the Raw generic. Using mem::transmute_copy is not very recommended maybe, but I hope this is used correctly. Here reference is of type &CFFooRef, which after the transmute_copy should be a CFFooRef. So the transmute_copy don't change the type, it just helps me take ownership of a dereferenced raw pointer. Which should be safe here unless I'm mistaken.

Maybe a more elegant solution is possible? I would be eager to learn a better way if there is one.

This is of course depending on the assumption that all TCFType::TypeRefs have the same size as *const c_void. This is true for all the possible subclasses of CFPropertyList at the moment and probably forever, but nothing is enforcing it.

If I add a second associated type, TCFType::RawTypeRef (or similar name), that we set to the corresponding __CFFoo type. Then I can refer to *const Self::RawTypeRef in places and do proper casts. From some early tinkering around it looks like that can get rid of all these strange solutions.

faern · 2017-11-24T19:40:36Z

core-foundation/src/propertylist.rs

-        assert!(propertylist.downcast::<_, CFString>().unwrap().to_string() == "Bar");
-        assert!(propertylist.downcast::<_, CFBoolean>().is_none());
+        assert!(propertylist.downcast::<CFString>().unwrap().to_string() == "Bar");
+        assert!(propertylist.downcast::<CFBoolean>().is_none());


Here one can see one of the clear benefits of this PR.

bors-servo · 2017-11-25T20:45:05Z

☔ The latest upstream changes (presumably #127) made this pull request unmergeable. Please resolve the merge conflicts.

faern · 2017-11-26T12:24:57Z

Now I'm much more satisfied with the solution to this. By adding a trait to the sys crate that provide helper functions for const raw pointers (all CFref-types) I'm now able to know more about TCFType::ConcreteTypeRef and thus perform conversion without any transmute_copy or other ugly pointer tricks.

faern · 2017-11-26T12:36:40Z

I have investigated a little bit how much this change would break published crates depending on the 0.4 version of core-foundation. I tried the following with the following results:

No change required:

cocoa_image
core-graphics
glutin
offscreen_gl_context

Some change required, but very little:

core-text
io-surface
font-loader

faern · 2017-11-26T12:38:32Z

core-foundation-sys/src/error.rs

@@ -15,7 +15,7 @@ use string::CFStringRef;
 #[repr(C)]
 pub struct __CFError(c_void);

-pub type CFErrorRef = *mut __CFError;
+pub type CFErrorRef = *const __CFError;


I'm not sure if this was *mut for a reason I have missed. But it was the only CF-ref typedef which was not *const so my guess is it was a typo. All tests of this crate and all dependant crates I tried work fine after this change.

bors-servo · 2017-11-28T17:10:53Z

☔ The latest upstream changes (presumably #139) made this pull request unmergeable. Please resolve the merge conflicts.

jdm

This is a nice improvement!

faern · 2017-11-29T11:43:32Z

@jdm Indeed. I like how much it simplifies. But @nox did not like that it breaks stuff, which it does. However updating the dependencies to work again is quite easy.

nox · 2017-11-29T11:45:35Z

However updating the dependencies to work again is quite easy.

It is easy but very fastidious, so I'll not let this PR land without all the others being ready too, including a PR to update them in Servo.

faern · 2017-11-29T12:01:02Z

@nox If it's released as 0.5.0 merging and publishing would not break anything because of semver. But I fully understand that you don't want to end up in a messy situation where only a few things are updated.

nox · 2017-11-29T12:05:38Z

@nox If it's released as 0.5.0 merging and publishing would not break anything because of semver. But I fully understand that you don't want to end up in a messy situation where only a few things are updated.

The issue arises when we start needing things that are unrelated to your changes, and 0.5.0 didn't land yet in servo/servo, so we must continue to maintain a 0.4 branch to get the unrelated changes in tree.

Of course, we should give you a hand and not tell you to do all the bumps.

faern · 2017-11-29T12:08:30Z

@nox I'll be happy to help upgrade the dependencies! But I'm not sure which they are. All the ones I can see are the ones listed under https://crates.io/crates/core-foundation/reverse_dependencies But I suspect that is not all of it.

If you list them here I can start submitting PRs to them. Given that you want this feature that is.

nox · 2017-11-29T12:11:22Z

Looking at the 0.2 to 0.3 bump commit gives an idea what to do.

faern · 2017-11-29T17:14:24Z

@nox @jdm What are your thoughts on the name ConcreteTypeRef? I think it's long and a bit redundant. "Concrete" is already implicit by the fact that each type must state the concrete type when they implement the trait. Having "Type" in a type is kind of a special case here where we mimic names from another API that we can't control, so not that bad, but works without IMO.

How about just calling it Ref? TCFType::Ref, or in another example context: <T as TCFType>::Ref. Would be more ergonomic to use and IMO conveys the same information.

If not, how about getting rid of "Concrete" and calling it TypeRef?

jrmuizel · 2017-12-23T18:54:55Z

@nox, @jdm ping

faern · 2017-12-28T15:18:58Z

@jrmuizel I didn't have time to help update servo and all dependencies yet. I still have some hope I will get to that though.

jdm

I really like these changes. Sorry that they sat around for so long!

jdm · 2018-01-10T20:51:39Z

core-foundation/src/base.rs

-    fn instance_of<OtherConcreteTypeRef,OtherCFType:TCFType<OtherConcreteTypeRef>>(&self) -> bool {
-        self.type_of() == <OtherCFType as TCFType<_>>::type_id()
+    fn instance_of<OtherCFType: TCFType>(&self) -> bool {
+        self.type_of() == <OtherCFType as TCFType>::type_id()


We should be able to use OtherCFType::type_id() now.

jdm · 2018-01-10T20:53:44Z

core-foundation/src/propertylist.rs

-    ) -> bool {
-        self.type_of() == <OtherCFType as TCFType<_>>::type_id()
+    pub fn instance_of<OtherCFType: TCFType>(&self) -> bool {
+        self.type_of() == <OtherCFType as TCFType>::type_id()


We should be able to do OtherCFType::type_id() now.

jdm · 2018-01-10T20:55:54Z

core-foundation/src/propertylist.rs

+    pub fn downcast<T: CFPropertyListSubClass>(&self) -> Option<T> {
+        if self.instance_of::<T>() {
+            unsafe {
+                let subclass_ref = <T as TCFType>::Ref::from_void_ptr(self.0);


We should be able to do T::Ref::from_void_ptr(self.0).

jdm · 2018-01-10T20:56:53Z

core-foundation-sys/src/base.rs

@@ -80,6 +80,23 @@ pub struct CFAllocatorContext {
    pub preferredSize: CFAllocatorPreferredSizeCallBack
 }

+/// Trait for all types which are Core Foundation reference types.


I think this commit should be reordered to come before 3688803.

Hmm. With "this commit" I assume you mean 0fc6b62 ? If so, it does come before 3688803

faern · 2018-01-10T21:11:11Z

@jdm My macOS dev environment was borked, so I could not build Servo. Thus I never came around to upgrade the dependencies from Servo down to here. Would be awesome to get it in though, not sure how to fix that dev env really...

faern · 2018-01-11T23:31:25Z

The travis build fails with a serious crash. It might be some bug I introduced, but it might also be something with Travis, since I can't reproduce it locally. Before I dive into this problem, does anyone know if this has show up before and/or is a known problem with this crate, or if it's something I likely introduced? @jdm ?

faern · 2018-01-23T22:05:16Z

core-foundation/src/array.rs

@@ -92,11 +92,6 @@ impl<T> CFArray<T> {
        }
    }

-    #[deprecated(note = "please use `as_untyped` instead")]
-    pub fn to_untyped(self) -> CFArray {


I realize now that my previous move to deprecate to_untyped and add as_untyped was not exactly making things more correct than before, if one should follow the API guidelines to the letter.
This removed to_untyped is a consuming convert (owned -> owned (non-Copy types)), so it should have been named into_untyped with that signature. So the old name was slightly "wrong".
On the other hand, the new as_untyped only borrows &self, but gives out an owned object (borrowed -> owned (non-Copy types)), so it should be named to_untyped, and not as_ since that is for conversions borrowed -> borrowed.

Do you think I should change the name of the method that will be present in the 0.5.0 release? Or is that too much nitpicking and too much changing the API back and forth? If it should be changed this would be the correct signature:

pub fn to_untyped(&self) -> CFArray { ... }

In line with all the new downcast_into methods, we could also add a consuming one that avoids bumping the retain count:

pub fn into_untyped(self) -> CFArray { ... }

Those seem like worthwhile changes.

Check. I'll add a commit for that. I'll push it after my other PR is merged, as this one will need rebasing/manual conflict resolution after that one anyway.

bors-servo · 2018-01-24T02:57:07Z

🔒 Merge conflict

bors-servo · 2018-01-24T02:57:17Z

☔ The latest upstream changes (presumably #145) made this pull request unmergeable. Please resolve the merge conflicts.

jdm · 2018-01-24T17:30:14Z

@bors-servo r+

bors-servo · 2018-01-24T17:30:14Z

📌 Commit 7e87a9d has been approved by jdm

bors-servo · 2018-01-24T17:30:18Z

⌛ Testing commit 7e87a9d with merge ec660b0...

Reference type as associated value instead of generic Each `CFFoo` has exactly one `CFFooRef` and which one is defined by `CFFoo`, not by its user. Thus the type of reference can be an associated type instead of a generic. As you can see this greatly simplifies things such as calling `instance_of` and `from_CFType_pairs` as well as using `CFPropertyListSubClass`. It basically removes one generic parameter from any method dealing with `TCFType`s in some way. This is a breaking change, so it would probably mean a `0.5.0` release if accepted. I don't know what your stance on breaking changes or version bumps is, so I don't know if you want this or not. But it would simplify the API, both here, but first and foremost in higher level crates using this.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/132)

bors-servo · 2018-01-25T02:43:22Z

☀️ Test successful - status-travis
Approved by: jdm
Pushing ec660b0 to master...

faern · 2018-01-25T07:28:56Z

Finally! \o/

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. But before the merge/publish of `core-foundation` I will prepare a set of PRs making sure the entire dependency graph of Servo is ready for this change and can be switched over to `0.5.0` directly. TODO before merge: - [x] Merge `core-foundation` PR and publish. - [x] Remove the last commit from this PR, so we depend on `core-foundation` from crates.io.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-graphics-rs/110)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. But before the merge/publish of `core-foundation` I will prepare a set of PRs making sure the entire dependency graph of Servo is ready for this change and can be switched over to `0.5.0` directly TODO before merge: - [x] Merge `core-foundation` PR and publish. - [x] Merge `core-graphics` PR and publish. - [x] Remove the last commit from this PR, so we depend on `core-foundation` from crates.io.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-text-rs/75)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. But before the merge/publish of `core-foundation` I will prepare a set of PRs making sure the entire dependency graph of Servo is ready for this change and can be switched over to `0.5.0` directly. TODO before merge: - [x] Merge `core-graphics` PR and publish. - [x] Remove the last commit from this PR, so we depend on `core-foundation` from crates.io.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/181)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. But before the merge/publish of `core-foundation` I will prepare a set of PRs making sure the entire dependency graph of Servo is ready for this change and can be switched over to `0.5.0` directly. TODO before merge: - [x] Merge `core-foundation` PR and publish. - [x] Remove the last commit from this PR, so we depend on code from crates.io.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/io-surface-rs/60)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. But before the merge/publish of `core-foundation` I will prepare a set of PRs making sure the entire dependency graph of Servo is ready for this change and can be switched over to `0.5.0` directly. TODO before merge: - [x] Merge `core-foundation`, `core-graphics` and `cocoa` PRs and publish. - [x] Remove the last commit from this PR, so we depend on code from crates.io.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/glutin/142)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. Before the merge/publish, a set of PRs making sure the entire dependency graph of Servo is ready for this change will be created. TODO before merge of this PR: - [x] Merge `io-surface` and `servo-glutin` PRs and publish. - [x] Remove the last commit from this PR, so we depend on code from crates.io. I did not read the contributing guidelines for this repo, as the link to it did not work for me.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/skia/148)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. Hopefully we can manage to bring Servo and its entire dependency tree up to date as rapidly as possible in combination with this, as to use only the new core-foundation in Servo and all its deps. :) TODO before merge: - [x] Merge `skia`. - [x] Remove the last commit from this PR, so we depend on code from crates.io.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-azure/282)

Upgrade core foundation This is a PR in a series of PRs originating at servo/core-foundation-rs#132 The plan is to make a breaking change to `core-foundation` and release it as `0.5.0`. Hopefully we can manage to bring Servo and its entire dependency tree up to date as rapidly as possible in combination with this, as to use only the new core-foundation in Servo and all its deps. :) TODO before merge: - [x] Merge `core-foundation`, `core-graphics`, `core-text`, `servo-glutin` PRs and publish. - [x] Merge `font-loader` PR and publish. - [x] Remove the last commit from this PR, so we depend on code from crates.io. - [x] Update Cargo.lock again, to not contain urls to temporary feature branhces.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/2299)

@jdm

Upgrade core foundation  This PR is the final one in a chain of PRs that tries to make a breaking change to `core-foundation`. This PR makes sure Servo only use the new, not yet released `core-foundation 0.5.0`. The changes in `core-foundation` and why it is not yet published can be read in the comments on this PR: servo/core-foundation-rs#132 Basically we want all of Servo (and deps) to be ready for a fairly swift upgrade from `core-foundation` `0.4.6` to `0.5.0` once it's released, so we don't end up in some state where we depend on, and have to maintain both, for an extended period of time. This PR is **not ready for merge** in its current state. The following must be done first: - [x] Merge servo/core-foundation-rs#132 and publish. - [x] Merge servo/core-graphics-rs#110 and publish. - [x] Merge servo/core-text-rs#75 and publish. - [x] Merge servo/cocoa-rs#181 and publish. - [x] Merge servo/glutin#142 and publish. - [x] Merge servo/io-surface-rs#60 and publish. - [x] Merge servo/skia#148. - [x] Merge servo/rust-azure#282. - [x] Merge servo/webrender#2299. - [x] Merge servo/surfman#118 and publish. - [x] Remove the commit in this PR that temporarily adds patch entries to `Cargo.toml`. - [x] Update Cargo.lock again to not point to my feature branches. For some of the dependencies I might accidentally have bumped the version as if it was a breaking change when it in fact wasn't. It was a bit messy to figure out all the details in so many and large crates. But hopefully I did not do the inverse, only bump the patch version where the change actually broke something. Ping @jdm and @nox who have been the ones commenting on the initial PR. ---  - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors  - [X] These changes do not require tests because they don't change any code, just upgrade dependencies.    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19759)

@jdm

…e-foundation); r=jdm  This PR is the final one in a chain of PRs that tries to make a breaking change to `core-foundation`. This PR makes sure Servo only use the new, not yet released `core-foundation 0.5.0`. The changes in `core-foundation` and why it is not yet published can be read in the comments on this PR: servo/core-foundation-rs#132 Basically we want all of Servo (and deps) to be ready for a fairly swift upgrade from `core-foundation` `0.4.6` to `0.5.0` once it's released, so we don't end up in some state where we depend on, and have to maintain both, for an extended period of time. This PR is **not ready for merge** in its current state. The following must be done first: - [x] Merge servo/core-foundation-rs#132 and publish. - [x] Merge servo/core-graphics-rs#110 and publish. - [x] Merge servo/core-text-rs#75 and publish. - [x] Merge servo/cocoa-rs#181 and publish. - [x] Merge servo/glutin#142 and publish. - [x] Merge servo/io-surface-rs#60 and publish. - [x] Merge servo/skia#148. - [x] Merge servo/rust-azure#282. - [x] Merge servo/webrender#2299. - [x] Merge servo/surfman#118 and publish. - [x] Remove the commit in this PR that temporarily adds patch entries to `Cargo.toml`. - [x] Update Cargo.lock again to not point to my feature branches. For some of the dependencies I might accidentally have bumped the version as if it was a breaking change when it in fact wasn't. It was a bit messy to figure out all the details in so many and large crates. But hopefully I did not do the inverse, only bump the patch version where the change actually broke something. Ping @jdm and @nox who have been the ones commenting on the initial PR. ---  - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors  - [X] These changes do not require tests because they don't change any code, just upgrade dependencies.   Source-Repo: https://github.com/servo/servo Source-Revision: e94a25949c924e086e38ef6bdbdc935734415b26 --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : 4e0c40d1610e09d5ecf823f51d42ede8706751e3

…e-foundation); r=jdm  This PR is the final one in a chain of PRs that tries to make a breaking change to `core-foundation`. This PR makes sure Servo only use the new, not yet released `core-foundation 0.5.0`. The changes in `core-foundation` and why it is not yet published can be read in the comments on this PR: servo/core-foundation-rs#132 Basically we want all of Servo (and deps) to be ready for a fairly swift upgrade from `core-foundation` `0.4.6` to `0.5.0` once it's released, so we don't end up in some state where we depend on, and have to maintain both, for an extended period of time. This PR is **not ready for merge** in its current state. The following must be done first: - [x] Merge servo/core-foundation-rs#132 and publish. - [x] Merge servo/core-graphics-rs#110 and publish. - [x] Merge servo/core-text-rs#75 and publish. - [x] Merge servo/cocoa-rs#181 and publish. - [x] Merge servo/glutin#142 and publish. - [x] Merge servo/io-surface-rs#60 and publish. - [x] Merge servo/skia#148. - [x] Merge servo/rust-azure#282. - [x] Merge servo/webrender#2299. - [x] Merge servo/surfman#118 and publish. - [x] Remove the commit in this PR that temporarily adds patch entries to `Cargo.toml`. - [x] Update Cargo.lock again to not point to my feature branches. For some of the dependencies I might accidentally have bumped the version as if it was a breaking change when it in fact wasn't. It was a bit messy to figure out all the details in so many and large crates. But hopefully I did not do the inverse, only bump the patch version where the change actually broke something. Ping jdm and nox who have been the ones commenting on the initial PR. ---  - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors  - [X] These changes do not require tests because they don't change any code, just upgrade dependencies.   Source-Repo: https://github.com/servo/servo Source-Revision: e94a25949c924e086e38ef6bdbdc935734415b26 UltraBlame original commit: 931c61b9f7a889329ab73d00414483af47ac3f7e

faern commented Nov 24, 2017

View reviewed changes

faern force-pushed the tcftype-ref-as-associated branch from ee441c5 to 1377b50 Compare November 26, 2017 12:22

faern commented Nov 26, 2017

View reviewed changes

faern mentioned this pull request Nov 26, 2017

Add basic dynamicstore wrapper mullvad/system-configuration-rs#2

Merged

faern force-pushed the tcftype-ref-as-associated branch 4 times, most recently from ca4834f to 93c9cba Compare November 27, 2017 14:10

jdm approved these changes Nov 28, 2017

View reviewed changes

faern force-pushed the tcftype-ref-as-associated branch from 93c9cba to 7a26e39 Compare November 29, 2017 11:53

faern force-pushed the tcftype-ref-as-associated branch from 7a26e39 to c7d610d Compare November 29, 2017 18:06

jdm approved these changes Jan 10, 2018

View reviewed changes

This was referenced Jan 11, 2018

Upgrade core foundation servo/core-graphics-rs#110

Merged

Upgrade core foundation servo/core-text-rs#75

Merged

faern mentioned this pull request Jan 11, 2018

Upgrade core foundation servo/cocoa-rs#181

Merged

2 tasks

faern added 2 commits January 23, 2018 22:41

Remove deprecated methods

70dd9c3

Clean up my own non-rustfmt style

c071ba7

faern commented Jan 23, 2018

View reviewed changes

faern force-pushed the tcftype-ref-as-associated branch from 63a43bb to 3fbdf42 Compare January 24, 2018 07:52

faern added 2 commits January 24, 2018 08:57

Rename as_untyped -> to_untyped, add into_untyped

ab08525

Bump version to 0.5.0

7e87a9d

faern force-pushed the tcftype-ref-as-associated branch from 3fbdf42 to 7e87a9d Compare January 24, 2018 07:58

bors-servo merged commit 7e87a9d into servo:master Jan 25, 2018

faern deleted the tcftype-ref-as-associated branch January 28, 2018 23:33

Reference type as associated value instead of generic #132

Reference type as associated value instead of generic #132

Conversation

faern commented Nov 24, 2017 • edited by larsbergstrom

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors-servo commented Nov 25, 2017

faern commented Nov 26, 2017

faern commented Nov 26, 2017

Choose a reason for hiding this comment

bors-servo commented Nov 28, 2017

jdm left a comment

Choose a reason for hiding this comment

faern commented Nov 29, 2017

nox commented Nov 29, 2017

faern commented Nov 29, 2017 • edited

nox commented Nov 29, 2017

faern commented Nov 29, 2017

nox commented Nov 29, 2017

faern commented Nov 29, 2017

jrmuizel commented Dec 23, 2017

faern commented Dec 28, 2017

jdm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

faern commented Jan 10, 2018

faern commented Jan 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors-servo commented Jan 24, 2018

bors-servo commented Jan 24, 2018

jdm commented Jan 24, 2018

bors-servo commented Jan 24, 2018

bors-servo commented Jan 24, 2018

bors-servo commented Jan 25, 2018

faern commented Jan 25, 2018

faern commented Nov 24, 2017 •

edited by larsbergstrom

faern commented Nov 29, 2017 •

edited