Unify conditional-const error reporting with non-const error reporting #134732

compiler-errors · 2024-12-24T18:24:11Z

This PR unifies the error reporting between ConditionallyConstCall and FnCallNonConst so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead.

This should ensure that as we constify traits in the standard library, we don't regress error messages for things like ==.

r? fmease or reassign

rustbot · 2024-12-24T18:24:21Z

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

RalfJung · 2024-12-25T09:16:41Z

Please give me a chance to review before landing this.

RalfJung

This looks great :) Just one minor nit.

compiler/rustc_const_eval/src/check_consts/ops.rs

compiler/rustc_const_eval/messages.ftl

compiler-errors · 2025-01-06T17:54:44Z

Ok this is ready now.

RalfJung

r=me with comment nit; the other point about whether the error is "this call is wrong" vs "this call is unstable" is pre-existing.

RalfJung · 2025-01-07T07:58:34Z

tests/ui/traits/const-traits/super-traits-fail-3.nyy.stderr

   |
+   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants


Looking at this, the output seems to be slightly different than for regular calls? Specifically, we don't seem to print this note for things that can be unstably called, we only print it for things that cannot be called at all.

So we don't distinguish cases where:

The feature gate is just not enabled

The feature gate is not enabled, and even if it were the ~const bounds are not satisfied

I think it would be nice to distinguish those, and only have this note be present in (2.), and not (1.). In the (1.) case, it would be even better to leave a note saying something along the lines of "this functionality is not stable in consts yet".

compiler/rustc_const_eval/src/check_consts/ops.rs

RalfJung · 2025-01-07T08:02:40Z

tests/ui/traits/const-traits/cross-crate.stock.stderr

   |
+   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
   = note: see issue #67792 <https://github.com/rust-lang/rust/issues/67792> for more information
   = help: add `#![feature(const_trait_impl)]` to the crate attributes to enable


Is this the error that shows up when the function is conditionally-const and we don't have enough trait bounds to know whether it is actually const, or when it is conditionally-const and we do have the trait bounds but we need to enable a nightly feature to use it?

The latter, but we don't distinguish the two per my comment above. I'll probably try to make this less misleading, but I'd prefer to do it as a follow-up. I think we can keep iterating on these errors as need (and as users complain).

compiler-errors · 2025-01-09T16:20:26Z

Edited the comment.

@bors r=RalfJung

bors · 2025-01-09T16:20:30Z

📌 Commit 924000d has been approved by RalfJung

It is now in the queue for this repository.

…nst-error-reporting, r=RalfJung Unify conditional-const error reporting with non-const error reporting This PR unifies the error reporting between `ConditionallyConstCall` and `FnCallNonConst` so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead. This should ensure that as we constify traits in the standard library, we don't regress error messages for things like `==`. r? fmease or reassign

bors · 2025-01-09T19:22:56Z

⌛ Testing commit 924000d with merge 246ac55...

bors · 2025-01-09T19:29:36Z

💔 Test failed - checks-actions

compiler-errors · 2025-01-09T19:31:03Z

@bors retry

curl: (22) The requested URL returned error: 404
curl: (22) The requested URL returned error: 404
curl: (22) The requested URL returned error: 404
curl: (22) The requested URL returned error: 404
ERROR: failed to download llvm from ci

    HELP: There could be two reasons behind this:
        1) The host triple is not supported for `download-ci-llvm`.
        2) Old builds get deleted after a certain time.
    HELP: In either case, disable `download-ci-llvm` in your config.toml:

    [llvm]
    download-ci-llvm = false

matthiaskrgr · 2025-01-09T19:34:51Z

@bors treeclosed=1000

happened here as well #135297 (comment)

rust-log-analyzer · 2025-01-09T19:40:30Z

The job armhf-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

curl: (22) The requested URL returned error: 404
curl: (22) The requested URL returned error: 404
ERROR: failed to download llvm from ci

    HELP: There could be two reasons behind this:
        1) The host triple is not supported for `download-ci-llvm`.
        2) Old builds get deleted after a certain time.
    HELP: In either case, disable `download-ci-llvm` in your config.toml:
    [llvm]
    download-ci-llvm = false
    
Build completed unsuccessfully in 0:00:23

tgross35 · 2025-01-10T06:20:27Z

@bors retry

oh, that failure is from before the previous retry so this did nothing

Rollup of 7 pull requests Successful merges: - rust-lang#132607 (Used pthread name functions returning result for FreeBSD and DragonFly) - rust-lang#134693 (proc_macro: Use `ToTokens` trait in `quote` macro) - rust-lang#134732 (Unify conditional-const error reporting with non-const error reporting) - rust-lang#135083 (Do not ICE when encountering predicates from other items in method error reporting) - rust-lang#135251 (Only treat plain literal patterns as short) - rust-lang#135320 (Fix typo in `#[coroutine]` gating error) - rust-lang#135321 (remove more redundant into() conversions) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#134732 - compiler-errors:unify-conditional-const-error-reporting, r=RalfJung Unify conditional-const error reporting with non-const error reporting This PR unifies the error reporting between `ConditionallyConstCall` and `FnCallNonConst` so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead. This should ensure that as we constify traits in the standard library, we don't regress error messages for things like `==`. r? fmease or reassign

rustbot assigned fmease Dec 24, 2024

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 Dec 24, 2024

This comment has been minimized.

Sign in to view

compiler-errors force-pushed the unify-conditional-const-error-reporting branch from 719498a to 541be58 Compare December 24, 2024 19:20

fmease assigned RalfJung Dec 25, 2024

RalfJung reviewed Dec 27, 2024

View reviewed changes

compiler/rustc_const_eval/src/check_consts/ops.rs Show resolved Hide resolved

lcnr reviewed Jan 6, 2025

View reviewed changes

compiler/rustc_const_eval/messages.ftl Show resolved Hide resolved

compiler-errors force-pushed the unify-conditional-const-error-reporting branch from 541be58 to db51aea Compare January 6, 2025 17:54

RalfJung reviewed Jan 7, 2025

View reviewed changes

fmease removed their assignment Jan 7, 2025

compiler-errors added 3 commits January 9, 2025 16:15

Add note back to conditionally-const error message

b321cd5

Make the non-const part swappable in the diagnostic

5a9f0be

Unify conditional and non const call error reporting

924000d

compiler-errors force-pushed the unify-conditional-const-error-reporting branch from db51aea to 924000d Compare January 9, 2025 16:20

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2025

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 9, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2025

jhpratt mentioned this pull request Jan 10, 2025

Rollup of 7 pull requests #135327

Merged

bors merged commit 9e24b6b into rust-lang:master Jan 10, 2025
6 of 7 checks passed

rustbot added this to the 1.86.0 milestone Jan 10, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unify conditional-const error reporting with non-const error reporting #134732

Unify conditional-const error reporting with non-const error reporting #134732

compiler-errors commented Dec 24, 2024

rustbot commented Dec 24, 2024

This comment has been minimized.

RalfJung commented Dec 25, 2024

RalfJung left a comment

compiler-errors commented Jan 6, 2025

RalfJung left a comment

RalfJung Jan 7, 2025

compiler-errors Jan 9, 2025

RalfJung Jan 7, 2025

compiler-errors Jan 9, 2025

compiler-errors commented Jan 9, 2025

bors commented Jan 9, 2025

bors commented Jan 9, 2025

bors commented Jan 9, 2025

compiler-errors commented Jan 9, 2025

matthiaskrgr commented Jan 9, 2025 •

edited

Loading

rust-log-analyzer commented Jan 9, 2025

tgross35 commented Jan 10, 2025 •

edited

Loading

		\|
		= note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

Unify conditional-const error reporting with non-const error reporting #134732

Unify conditional-const error reporting with non-const error reporting #134732

Conversation

compiler-errors commented Dec 24, 2024

rustbot commented Dec 24, 2024

This comment has been minimized.

RalfJung commented Dec 25, 2024

RalfJung left a comment

Choose a reason for hiding this comment

compiler-errors commented Jan 6, 2025

RalfJung left a comment

Choose a reason for hiding this comment

RalfJung Jan 7, 2025

Choose a reason for hiding this comment

compiler-errors Jan 9, 2025

Choose a reason for hiding this comment

RalfJung Jan 7, 2025

Choose a reason for hiding this comment

compiler-errors Jan 9, 2025

Choose a reason for hiding this comment

compiler-errors commented Jan 9, 2025

bors commented Jan 9, 2025

bors commented Jan 9, 2025

bors commented Jan 9, 2025

compiler-errors commented Jan 9, 2025

matthiaskrgr commented Jan 9, 2025 • edited Loading

rust-log-analyzer commented Jan 9, 2025

tgross35 commented Jan 10, 2025 • edited Loading

matthiaskrgr commented Jan 9, 2025 •

edited

Loading

tgross35 commented Jan 10, 2025 •

edited

Loading