Make TooGeneric error in WF checking a proper error
#68388
Conversation
rust-highfive
added
the
S-waiting-on-review
| // prove are well-formed. | ||
| let mut err = self.tcx.sess.struct_span_err( | ||
| span, | ||
| "cannot determine that constant is always well-formed", |
There was a problem hiding this comment.
We probably shouldn't talk about WF in diagnostics.
The way I was initially approaching this (see variant names, like ConstEvaluatable in Predicate and ConstEvalFailure here) would suggest something more like:
constant expression depends on generic parameters
followed by explaining that it may fail to evaluate depending on the choice of generics.
There was a problem hiding this comment.
Oh and you can bypass the problem of explaining to the user how to make it work, by linking to a rust-lang/rust issue (ideally a new one without any preexisting discussion) titled something like "Constant expressions using generic params require weird where clauses." with a "canonical" example.
Note that the "canonical" example doesn't work yet, because ConstEvaluatable requirements from bounds aren't implied in the body (maybe they need to be added to ParamEnv, and then looked up in there?).
I'm not even sure we can (ab)use the where TyAlias<T, {N}>:, pattern like that, usually WF semantics would require that the definition that where is attached to proves the WF, instead of deferring that to users of that definition.
I would want a @rust-lang/wg-traits confirmation that we want to implement that behavior (as it's not limited to const generics, it applies to any constant expressions using generic parameters, e.g. [u8; size_of::<T>()], so it might impact stable).
|
Fixed. |
This comment has been minimized.
This comment has been minimized.
`TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.
|
@bors r+ |
|
📌 Commit dd0507c has been approved by |
bors
added
S-waiting-on-bors
Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing. Fixes rust-lang#66962. r? @eddyb
Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing. Fixes rust-lang#66962. r? @eddyb
Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing. Fixes rust-lang#66962. r? @eddyb
Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing. Fixes rust-lang#66962. r? @eddyb
Rollup of 10 pull requests Successful merges: - #67195 ([experiment] Add `-Z no-link` flag) - #68253 (add bare metal ARM Cortex-A targets to rustc) - #68361 (Unbreak linking with lld 9 on FreeBSD 13.0-CURRENT i386) - #68388 (Make `TooGeneric` error in WF checking a proper error) - #68409 (Micro-optimize OutputFilenames) - #68410 (Export weak symbols used by MemorySanitizer) - #68425 (Fix try-op diagnostic in E0277 for methods) - #68440 (bootstrap: update clippy subcmd decription) - #68441 (pprust: use as_deref) - #68462 (librustc_mir: don't allocate vectors where slices will do.) Failed merges: r? @ghost
TooGenericis encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation time errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.Fixes #66962.
r? @eddyb