Skip to content
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

Fix const-fn check in const_eval #118004

Closed
wants to merge 1 commit into from
Closed

Conversation

ouz-a
Copy link
Contributor

@ouz-a ouz-a commented Nov 17, 2023

We were unable to capture constness of the f and ended up with ICE, this PR checks constness of the callee. I also don't understand why we are not checking constness via calling call_kind and capturing FnCall.

Fixes #117795

@rustbot
Copy link
Collaborator

rustbot commented Nov 17, 2023

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 17, 2023
call_source.from_hir_call(),
None,
);
if let call_kind::CallKind::FnCall { fn_trait_id: _, self_ty } =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use let-chains here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made it more readable now

@oli-obk
Copy link
Contributor

oli-obk commented Nov 18, 2023

We should probably just rip out the trait method call logic here and solely rely on effect checks. I don't like making const checks have more special casing logic, but also won't review in detail until January. So I don't have anything useful to say about the code change

cc @fee1-dead

if let call_kind::CallKind::FnCall { fn_trait_id: _, self_ty } =
call_kind
&& let FnDef(def_id, ..) = self_ty.kind()
&& tcx.is_const_fn_raw(*def_id)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is_const_fn_raw only checks whether the function is const, and not whether it is const-stable. We'd need a test to check whether this would silently allow calling functions that are not const-stable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do we do that kind of check ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if other parts of the const checking code already check for const stability, so the first step would be creating an auxiliary ui test where upstream has a const-unstable function and downstream tries to call that function without the feature enabled (following the snippet for this ICE). If it already passes, then great. If it doesn't, we can change this from is_const_fn_raw to is_const_fn

@fee1-dead
Copy link
Member

We should probably just rip out the trait method call logic here and solely rely on effect checks.

Yes, that would be the goal. I did leave a comment up there // FIXME(effects) do we need this? suggesting potential removal.

@fee1-dead
Copy link
Member

After looking a little bit into this, it looks like the actual ICE isn't because we aren't doing enough checks here, but probably because of something deeper than that. If I recall correctly, we used to remap the callee DefId from a trait method into a method from the actual concrete implementation, but there were problems with that so we stopped doing that. The ICE is then caused by us not thinking Fn::call as a const function thus triggering the ICE later. We still shouldn't allow people who haven't enabled feature(const_trait_impl) to do calls like these. Maybe it should be matched as a builtin impl source somewhere above?

@fee1-dead
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 24, 2023
@bors
Copy link
Contributor

bors commented Dec 10, 2023

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

@Dylan-DPC
Copy link
Member

@ouz-a any updates on this?

@oskgo
Copy link
Contributor

oskgo commented Jul 26, 2024

@ouz-a

Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you are going to continue please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive

@oskgo oskgo closed this Jul 26, 2024
@rustbot rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ice: calling const FnDef errored when it shouldn't
9 participants