Allow using fn pointers in const fn with unleash miri #64635
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
|
@oli-obk so surprisingly this works, and the feature gate works as well, but when the feature is activated I think we should diagnose some issues (e.g. using non- |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Centril
reviewed
Sep 21, 2019
| @@ -0,0 +1,20 @@ | |||
| warning: function is never used: `double` | |||
There was a problem hiding this comment.
The dead_code warnings are off-topic and shouldn't be here.
| x(y) | ||
| } | ||
|
|
||
| const Y: usize = bar(X, 2); |
There was a problem hiding this comment.
This and Z should not type-check.
There was a problem hiding this comment.
This is the same issue mentioned in the OP and here and should be fixed by fixing that as well.
| sym::const_fn_ptr, | ||
| self.span, | ||
| GateIssue::Language, | ||
| "function pointers in const fn are unstable", |
There was a problem hiding this comment.
Suggested change
| "function pointers in const fn are unstable", | |
| "function pointers in `const fn` are unstable", |
There was a problem hiding this comment.
The other errors do not follow this style. cc @oli-obk
There was a problem hiding this comment.
The other errors are wrong then.
There was a problem hiding this comment.
Agreed, but I'd rather not touch them before #64470 is merged
There was a problem hiding this comment.
I think that PR also enables function pointer calling behind unleash
gnzlbg
commented
Sep 21, 2019
| const X: fn(usize) -> usize = double; | ||
|
|
||
| const fn bar(x: usize) -> usize { | ||
| X(x) |
There was a problem hiding this comment.
@oli-obk this is the issue that we chatted about. Note that bar can be called at run-time, but it will always fail with a constant evaluation error when called in a const context because it tries to call a non-const fn.
I'm not sure how to generate an error in this case. Right now it generates a constant-evaluation error when used in const-context, but it would be nice to generate a better error message.
There was a problem hiding this comment.
XD welcome to RFC territory. This needs an RFC, because we need surface language changes in order to differentiate between callable and not callable function pointers.
This is what I meant by "we can do it behind a feature gate for experimentation, but we'll never be able to stabilize it.". For all intents and purposes, this is const unsound just like casting pointers to usize or comparing pointers. The pointer ops have been made unsafe for this reason, so maybe we make this unsafe, too? Idk. Seems all fishy without an RFC but as an experimental unstable feature seems fine
There was a problem hiding this comment.
@oli-obk I've updated the OP with a description of the semantics that this PR implements. I'm not sure why this would be const unsound. The const fn taking pointers should be parametric over the pointer constness, and we should be able to reject that at type checking time without new syntax AFAICT.
There was a problem hiding this comment.
Sure, that would be one way to do it, it would mean you can't pass any function pointers, because there are no const function pointers. Not compiling is the current semantics and is totally sound. This is all discussed in my RFC and needs its own RFC. I'm 🤧 right now and my brain is mush. I'd prefer not to write out an explanation right now.
There was a problem hiding this comment.
Ah I see what you mean now.
There was a problem hiding this comment.
I am not sure if we need language syntax for this initially, e.g., we could just add a type that users cannot write, add coercions to it from const fns, and then do the const parametricity part. But that's 99% of the work, and at that point not allowing people to write down the type feels like unnecessary.
Either way, the intent of this PR was never to go through all that trouble.
oli-obk
reviewed
Sep 21, 2019
| self.span, | ||
| &format!("function pointers are not allowed in const fn")); | ||
| err.emit(); | ||
| if !(unleash_miri || const_fn_ptr) { |
There was a problem hiding this comment.
Since the feature is inherently broken, maybe just do the unleash part and no feature gate?
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
So I will remove the feature gate, and only allow this behind the unleash miri part. |
gnzlbg
force-pushed
the
const_fn_ptr
branch
from
83cc2f3 to
d434496
Compare
gnzlbg
changed the title
|
I've done that. |
|
@bors r+ |
|
📌 Commit d434496 has been approved by |
bors
added
S-waiting-on-bors
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
@bors r- |
bors
added
S-waiting-on-author
|
@bors r+ |
|
📌 Commit 9d4053f has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Sep 21, 2019
Allow using fn pointers in const fn with unleash miri
This allows using function pointers in const fns when `-Zunleash-the-miri-within-you` is enabled.
If the call to the `const fn` happens in a `const`-context, the function pointer is required to point to a `const fn`:
```rust
fn non_const_fn() -> i32 { 42 }
const fn const_fn() -> i32 { 42 }
const fn foo(x: fn() -> i32) -> i32 { x() }
let x: i32 = foo(non_const_fn_ptr); // OK
let y: i32 = foo(const_fn_ptr); // OK
const X: i32 = foo(non_const_fn_ptr); // ERROR: `non_const_fn` is not `const fn`
const Y: i32 = foo(const_fn_ptr); // OK
```
r? @oli-obk
bors
added a commit
that referenced
this pull request
Sep 22, 2019
Rollup of 9 pull requests Successful merges: - #63907 (Add explanation to type mismatch involving type params and assoc types) - #64615 (rustbuild: Turn down compression on exe installers) - #64617 (rustbuild: Turn down compression on msi installers) - #64618 (rustbuild: Improve output of `dist` step) - #64619 (Fixes #63962. Hint about missing tuple parentheses in patterns) - #64634 (Update to LLVM 9.0.0) - #64635 (Allow using fn pointers in const fn with unleash miri) - #64660 (unify errors for tuple/struct variants) - #64664 (fully remove AstBuilder) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows using function pointers in const fns when
-Zunleash-the-miri-within-youis enabled.If the call to the
const fnhappens in aconst-context, the function pointer is required to point to aconst fn:r? @oli-obk