[WIP] Start adding support for opt-in built-in traits #14371
Conversation
| @@ -57,6 +57,8 @@ pub struct Arc<T> { | |||
| x: *mut ArcInner<T>, | |||
| } | |||
|
|
|||
| impl<T> Share for Arc<T> {} | |||
There was a problem hiding this comment.
Doesn't this need T: Share? (And can't it be #[deriving]'d?)
There was a problem hiding this comment.
ops, yes, it should be T: Share (in which case it can use the deriving attr).
There was a problem hiding this comment.
It seems that most of these manual impls in this patch could be done by #[deriving]? (Also, what about built-in traits like Send?)
There was a problem hiding this comment.
Yeah, I must have added them before the deriving patch landed. The work for Send and Copy will happen in a separate PR. I've already started working on it but it's easier to review / work on if we keep them separate.
There was a problem hiding this comment.
Theoretically each additional trait is just removing it from type contents and adding the type_fulfills_TRAIT function (and calling it in the right place?)? (i.e it should be a very small patch?)
I'll defer to your experience in this code though.
There was a problem hiding this comment.
(Actually, on second thoughts, IMO, it would be better to avoid #[deriving] for Arc, since it has a raw pointer.)
There was a problem hiding this comment.
Yeah, the opt-in specific changes shouldn't be big. Adding a type_fulfills_X and trait related tests would be enough. What I can't estimate, though, is the fallout for each case. The biggest one seems to be Send.
Fallout changes are pretty isolated in per-module commits (as much as possible :D). However, it's probably easier from a reviewing/rebasing perspective to check/work on trait implementations if they are in separate reviews. TBH, I'm happy either way. I like the idea of this RFC landing all together, although that probably means it'll take longer and it'll be more painful rebase-wise. 😄
This commit adds a function in vtable to find the vtables for a trait implementation on a type. cc rust-lang#13231
The bounds visitor checks looks for built-in traits implementations and verifies that the type fulfills such trait. [RFC rust-lang#3] cc rust-lang#13231 [breaking-change]
|
Closing due to inactivity. I think @nikomatsakis has some changes in mind for the design as well. Start this again later. |
Preserve comments for extracted block expression in 'extract_function' Fix rust-lang#14371 Preserve comments for extracted block expression in 'extract_function'. In the original implementation, `block.statements()` was used to construct a new function, removing the comments within the block. In the updated implementation, we use manual traversal of nodes and `hacky_block_expr` to generate a new block, thereby preserving the comments.
This is the first PR adding actual logic for this RFC.
It's still a work in progress but I'd like to start getting feedback from the community.
The PR consists in:
Sharetrait for the types requiring it. Note that the implementations added are the ones required to make rust compile. There may definitely be missing implementations for this trait.There are still some issues I'm working on. For instance, some fields in the
typeck-bounds-share-implsare commented out because I hit a compiler bug if they're not. The compiler bug is not really clear to me but I'm working with Niko on figuring what's going on there.(sorry for taking so long to post this)
cc @nikomatsakis @pcwalton
cc #13231
[breaking-change]
[RFC#3]