-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Implement unique types per fn item, rather than having all fn items have fn pointer type #19891
Conversation
|
||
self.unpack_actual_value(b, |sty_b| { | ||
debug!("coerce_from_bare_fn(a={}, b={})", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit - debug text needs changing
r=me with nits fixed |
e4ec6c7
to
a568b53
Compare
@nick29581 I was thinking, perhaps we should have special type rules for this case so that we permit |
c25c3a8
to
89afce2
Compare
Re-examining the fallout, it's clear that the most useful change would be to propagate coercions through |
89afce2
to
1085a6b
Compare
1085a6b
to
0263c41
Compare
0263c41
to
973d26e
Compare
df31867
to
96ffaf5
Compare
96ffaf5
to
dd18fa2
Compare
dd18fa2
to
2f04db6
Compare
type of a fn item or a fn pointer, which are now differentiated. Introduce coercion from fn item to fn pointer.
cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
post-unboxed-closure-conversion. This requires a fair amount of annoying coercions because all the `map` etc types are defined generically over the `F`, so the automatic coercions don't propagate; this is compounded by the need to use `let` and not `as` due to stage0. That said, this pattern is to a large extent temporary and unusual.
…cions between them.
…cion changes, and also stop printing semi-useless inference by-products.
2f04db6
to
763152b
Compare
Conflicts: src/libcore/str.rs src/librustc_trans/trans/closure.rs src/librustc_typeck/collect.rs src/libstd/path/posix.rs src/libstd/path/windows.rs
fix breakage from rust-lang/rust#19891
This is part of the coercion RFC but also makes sense given unboxed closures. The idea is that every fn item has its own type. This type can be coerced to a fn pointer but is not a fn pointer. This PR does almost all the end-user visible changes, but leaves one thing undone: the representation of an instance of a "fn item type" is still a fn pointer at runtime. A later PR will have to change them to zero-sized values (I'll open an isssue on this).
This is a [breaking-change]. In general, the coercion rules ensure that code which used to take a
fn()
type continus to work, but there are some patterns that need to be changed to insert explicit coercions.Example 1:
If/match arms sometimes require explicit types now:
Example 2:
Generic functions are another place where coercions often fail to trigger. Example:
This one may or may not get fixed going forward; inserting coercions in cases like these involves subtle changes to program semantics that may not be appropriate.
r? @nick29581