Skip to content

fix: Do not infer signatures, instead infer anon consts in them#22198

Open
ChayimFriedman2 wants to merge 2 commits intorust-lang:masterfrom
ChayimFriedman2:anon-consts
Open

fix: Do not infer signatures, instead infer anon consts in them#22198
ChayimFriedman2 wants to merge 2 commits intorust-lang:masterfrom
ChayimFriedman2:anon-consts

Conversation

@ChayimFriedman2
Copy link
Copy Markdown
Contributor

@ChayimFriedman2 ChayimFriedman2 commented Apr 27, 2026

See the Zulip discussion for details, but in short:

  • This allows us to easily set the expected type.
  • They can have proper MIR an eval, preventing the need for hacks like fixme_resolve_all_clone().

This also fixes a bunch of old inference failures caused by us unable to evaluate constants.

In order to make them visible to the IDE layer, each query that can create anon consts now keeps a list of the anon consts it created. The expression store also gains an ability to find the root expression of something. Then, in Semantics, when wanting to find inference info for something, we find its root expr, then search it in the list of anon consts defined by the body.

This should reduce our diagnostics on self by at least two (they're caused by failure to evaluate consts on to_le_bytes(), we even have a test for that).

Blocked on #22194.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 27, 2026
@ChayimFriedman2 ChayimFriedman2 marked this pull request as draft April 27, 2026 23:32
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 27, 2026
223..227 'iter': IntoIter<u8>
230..231 'a': Vec<u8>
230..243 'a.into_iter()': IntoIter<u8>
322..323 '1': usize
Copy link
Copy Markdown
Contributor Author

@ChayimFriedman2 ChayimFriedman2 Apr 27, 2026

Choose a reason for hiding this comment

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

Previously we inferred all expressions in the signature. Now we skip literals and paths (we don't create an anon const for them) to save time and space. The net effect is that they aren't shown in tests and to IDE, although it's possibly to support them for IDE in little effort.

View changes since the review

);
// note: this may break later if we add more consteval. it just needs to be something that our
// consteval engine doesn't understand
check_assist_not_applicable(
Copy link
Copy Markdown
Contributor Author

@ChayimFriedman2 ChayimFriedman2 Apr 27, 2026

Choose a reason for hiding this comment

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

It's not easy to support this now, since the type does not contain an error type anymore: it just has an anon const that fails to evaluate, which causes it to fail to normalize. But I've realized this test is no longer needed, since _ in arrays is supported by now.

View changes since the review

See [the Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Anon.20consts.20for.20everything/with/587684630) for details, but in short:
 - This allows us to easily set the expected type.
 - They can have proper MIR an eval, preventing the need for hacks like `fixme_resolve_all_clone()`.

This also fixes a bunch of old inference failures caused by us unable to evaluate constants.

In order to make them visible to the IDE layer, each query that can create anon consts now keeps a list of the anon consts it created. The expression store also gains an ability to find the root expression of something. Then, in `Semantics`, when wanting to find inference info for something, we find its root expr, then search it in the list of anon consts defined by the body.
@ChayimFriedman2 ChayimFriedman2 marked this pull request as ready for review April 28, 2026 17:41
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants