Add very basic "comptime" fn implementation#148820
Add very basic "comptime" fn implementation#148820oli-obk wants to merge 7 commits intorust-lang:mainfrom
Conversation
|
Some changes occurred in compiler/rustc_attr_parsing Some changes occurred in compiler/rustc_passes/src/check_attr.rs Some changes occurred in compiler/rustc_hir/src/attrs Some changes occurred to the CTFE machinery Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
|
rustbot has assigned @JonathanBrouwer. Use |
This comment has been minimized.
This comment has been minimized.
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
This comment has been minimized.
This comment has been minimized.
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred to constck cc @fee1-dead |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| } | ||
| } | ||
| } else if ccx.tcx.constness(callee) != hir::Constness::Const { | ||
| } else if ccx.tcx.constness(callee) != hir::Constness::Maybe { |
There was a problem hiding this comment.
What part? The rename or the inequality?
There was a problem hiding this comment.
The inequality. I feel like this should be if == hir::Constness::NotConst?
| let num_args = fields.len(); | ||
| let func = | ||
| if context == hir::Constness::Const { called_in_const } else { called_at_rt }; | ||
| if context == hir::Constness::Maybe { called_in_const } else { called_at_rt }; |
There was a problem hiding this comment.
I feel like we shouldn't add another variant to hir::Constness given how this changes a lot of other things which might be a headache to update if we were to add comptime impls in the future, etc. Would it make sense to keep the hir:Constness::{,Not}Const, and extract the comptime enum specifically to a new enum? Might be a bit more work to do but worth it IMO, and might be better than doing it in a followup.
There was a problem hiding this comment.
I can draft up a version of that, but mostly as a counterexample to why we shouldn't do that. This enum mirrors the BoundConstness perfectly (and those should probably be merged), because there are only those 3 options. Having two separate enums creates an odd space where we need to reject an illegal state in the type system instead of just in the parser or ast lowering
| x | not const | const |
|---|---|---|
| not comptime | fn | const fn |
| comptime | comptime fn | ??? |
There was a problem hiding this comment.
If you're worried about footguns I think we could try to remove impl PartialEq for Constness and require exhaustive handling at all sites.
There was a problem hiding this comment.
Alternatively I can make the "alwaysness" of the Comptime variant be a field on the Const/Maybe variant. This way you can't accidentally forget to handle it, but Const and Maybe end up generally handled together unless explicitly differentiated
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
I made this change, which made the "renaming Constness variants to match BoundConstness" change a little weird, so I removed that and will look into it in another PR. Maybe by changing BoundConstness to match Constness instead of the other way around
|
Reminder, once the PR becomes ready for a review, use |
|
☔ The latest upstream changes (presumably #149478) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #143924) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Is this PR still intended to move forward, or has the work been superseded elsewhere? |
|
I have some review comments to address and some heavy rebasing to do :D |
| #[rustc_comptime] | ||
| fn always_const<T: const Trait>() { | ||
| T::method() | ||
| } |
There was a problem hiding this comment.
No Action Required: Makes me wish the current const modifier was actually named const?, to imply it can be called in comptime, and can be called at runtime. That way, const would mean must be called in comptime, and the absence of const means can't be called in comptime. It doesn't really matter, since this is a compiler feature, but it'd be nicer for users to understand what's going on.
| #[rustc_comptime] | ||
| const fn foo() {} | ||
| //~^ ERROR a function cannot be both `comptime` and `const` |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
It's actually easier this way for the compiler, because it's now trivial to reject [const] bounds
There was a problem hiding this comment.
It's also nowhere near the final syntax, just sth to enable the feature
There was a problem hiding this comment.
Ahh ok, I assumed this was mostly a stylistic choice. If it's more consistent with the rest of the compiler that makes sense.
| let num_args = fields.len(); | ||
| let func = | ||
| if context == hir::Constness::Const { called_in_const } else { called_at_rt }; | ||
| if context == hir::Constness::Maybe { called_in_const } else { called_at_rt }; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
…d in comptime fn
…rgetted at what it does
01088b9 to
d092d4e
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
View all comments
Implements functions that cannot be called at runtime (and thus also not from normal const functions, as those could be called from runtime).
This is done via the internal attribute
rustc_comptimethat can be added to normal functions, turning them into compile-time-only functions.Because @fee1-dead and @compiler-errors did amazing work, we even get trait bounds that work inside comptime fns: via unconditionally-const
const Traitbounds.Use cases are
project goal issue: rust-lang/rust-project-goals#406
no tracking issue until we have a feature gate and some sort of syntax
cc @scottmcm as the T-lang goal champion