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

"constant expression depends on a generic parameter" error can be improved. #71142

Open
eddyb opened this issue Apr 14, 2020 · 0 comments
Open
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. PG-const-generics Project group: Const generics T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Apr 14, 2020

Original discussion happened at #70452 (comment).


This was my last proposal in that comment thread (#70452 (comment)):

So perhaps a better phrasing for the error itself might be "cannot prove/determine/guarantee/etc. that constant expression will evaluate successfully" and then we can search its Substs for type/const parameters and list them out to give the more helpful information.

We should also link https://github.com/rust-lang/rust/issues/68436, in some sort of help messaging along the lines of "there is no way to currently write the necessary where clause, watch this space".

cc @rust-lang/wg-diagnostics @varkor @yodaldevoid

@eddyb eddyb added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 14, 2020
@jonas-schievink jonas-schievink added A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints labels Apr 14, 2020
jiegec pushed a commit to AOSC-Tracking/rustc that referenced this issue Feb 10, 2024
If we start with an i128 shift, the initial shift amount would
usually have zeros in bit 8 and above. xoring the shift amount with
-1 will set those upper bits to 1. If DAGCombiner is able to prove those
bits are now 1, then the shift that uses the xor will be replaced
with undef. Which we don't want.

Reduce the xor constant to VT.bits-1 where VT is half the size of
the larger shift type. This avoids toggling the upper bits. The
hardware shift instruction only uses the lower bits of the shift
amount. I assume the code used NOT because the hardware doesn't
use the upper bits, but that isn't compatible with the LLVM poison
semantics.

Fixes rust-lang#71142.
jiegec pushed a commit to AOSC-Tracking/rustc that referenced this issue Feb 11, 2024
If we start with an i128 shift, the initial shift amount would
usually have zeros in bit 8 and above. xoring the shift amount with
-1 will set those upper bits to 1. If DAGCombiner is able to prove those
bits are now 1, then the shift that uses the xor will be replaced
with undef. Which we don't want.

Reduce the xor constant to VT.bits-1 where VT is half the size of
the larger shift type. This avoids toggling the upper bits. The
hardware shift instruction only uses the lower bits of the shift
amount. I assume the code used NOT because the hardware doesn't
use the upper bits, but that isn't compatible with the LLVM poison
semantics.

Fixes rust-lang#71142.
@fmease fmease added the PG-const-generics Project group: Const generics label Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. PG-const-generics Project group: Const generics T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants