Skip to content

Implement unused pattern bindings, continued#6518

Merged
jonmeow merged 52 commits intocarbon-language:trunkfrom
burakemir:unused_pattern_bindings_impl_continued
Feb 20, 2026
Merged

Implement unused pattern bindings, continued#6518
jonmeow merged 52 commits intocarbon-language:trunkfrom
burakemir:unused_pattern_bindings_impl_continued

Conversation

@burakemir
Copy link
Contributor

Implementation of unused pattern bindings #2022, continued.

Whereas previous PR #6460 took care of parsing, and PR #6479 prepared the stage by using _ in some test cases, this PR has the the actual implementation, using a simple dataflow analysis.

Implements the following diagnostics in check:
* [UnusedBinding] warning, a binding is unused.
* [UnusedPatternNoBindings] warning, "unused" marker has no effect
* [UnusedMarkerInDeclaration] error, "unused" is for definitions
* [UnusedButUsed] error, marker is contradicting use
* [UnusedButUsedHere] note, shows first use

Updates all test cases which contain unused markers, and
replaces TODOs with actual warnings (or evidence of absence
of warnings).

Unfortunately, the prevalence of unused bindings in test cases
makes the change rather large.
@burakemir burakemir requested a review from a team as a code owner December 17, 2025 19:53
@burakemir burakemir requested review from jonmeow and removed request for a team December 17, 2025 19:53
@danakj danakj changed the title Implemend unused pattern bindings, continued Implement unused pattern bindings, continued Dec 17, 2025
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! I've done a first pass.

In particular regarding my comments on CARBON_KIND_SWITCH and things like AnyBindingPattern, note that comes up multiple times in this PR. We use those a lot to reduce the weight of these sorts of repeat inst kind checks, hopefully they're helpful here!

Copy link
Contributor Author

@burakemir burakemir left a comment

Choose a reason for hiding this comment

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

Thanks for the suggestions! PTAL.

@burakemir burakemir requested a review from jonmeow December 18, 2025 15:52
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

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

Stepping back a moment, I was thinking again about the responses on #6448. I went back to @zygoloid because of this comment, trying to figure out when he meant that changing a name to _ should diagnose. After discussion, here are a couple specific things:

fn F(x: i32) {
  return;
  // When a non-`unused` binding is used in unreachable code,
  // that should not diagnose because changing it to `_` would be a name lookup diagnostic here.
  x = 0;
}

fn F(unused x: i32) {
  return;
  // When an explicitly `unused` name is used in unreachable code,
  // both warning and not warning are okay choices.
  x = 0;
}

I was looking through tests, trying to figure out if cases like this are covered (it looks like tests may not be covering unreachable dataflow?). In particular I'm noting this, because I think it may have interesting implications on dataflow; is the current setup giving desired answer for references to x: i32 (no unused)?

For return flow, zygoloid reminded me we have IsCurrentPositionReachable. We use this to take advantage of some flow data that check accumulates (rather than as a separate dataflow step, as proposed here). Had you looked at using IsCurrentPositionReachable for the unused-but-used case?

@jonmeow
Copy link
Contributor

jonmeow commented Dec 18, 2025

Also, quick small note in addition to the above, I know it's a big question but I'm also going to be out soon for a while; I'll probably be handing off review tomorrow since even though people are out a lot for the holidays, I'm probably coming back later than others. :)

@burakemir burakemir requested a review from jonmeow February 9, 2026 12:12
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

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

Thanks! I think this is close to being ready to submit. Can you please update it against trunk, when you think it's ready for a merge? That way we can handle actually doing the merge.

Copy link
Contributor Author

@burakemir burakemir left a comment

Choose a reason for hiding this comment

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

Thanks for the review, Will rebase now.

@burakemir burakemir requested a review from a team as a code owner February 13, 2026 13:26
@burakemir burakemir requested a review from jonmeow February 13, 2026 13:27
@burakemir
Copy link
Contributor Author

Added a merge commit. This should be good to land. Note that I don't have rights to merge.

@jonmeow
Copy link
Contributor

jonmeow commented Feb 13, 2026

It looks like you still have conflicts, with older PRs (e.g. toolchain/check/BUILD last updated a week ago). Would you be interested in fixing the outstanding conflicts, or do you want me to finish the merge work?

To be sure, you should probably be doing something like git fetch upstream && git merge upstream/trunk to fetch the latest changes. You can also double-check on the PR to look if GitHub says there are still outstanding conflicts.

@zygoloid zygoloid removed their request for review February 13, 2026 21:14
@burakemir
Copy link
Contributor Author

Done the proper merge commit from trunk now.
Please merge.

@jonmeow jonmeow force-pushed the unused_pattern_bindings_impl_continued branch from 36ce922 to 00d166d Compare February 17, 2026 21:11
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

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

It looks like a PR got in. I was getting to merge that (you might note me having pushed to this PR, I undid it), but was double-checking tests were passing (bazel test //...) before that. It looks like you have a couple failing tests already, so I backed out my merge -- do you want to fix tests and merge again?

Comment on lines 18 to 21
// CHECK:STDERR: generic_default_fn.carbon:[[@LINE+4]]:6: warning: binding `T` unused [UnusedBinding]
// CHECK:STDERR: fn I(T:! type).F[ref self: Self]() -> Self* { return &self; }
// CHECK:STDERR: ^
// CHECK:STDERR:
Copy link
Contributor

Choose a reason for hiding this comment

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

This test is failing. Maybe this could be _:! type?

Copy link
Contributor Author

@burakemir burakemir Feb 18, 2026

Choose a reason for hiding this comment

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

We cannot use _ here, since proposal #3763 explicitly disallows this and considers it a difference in redeclaration.

However, if we were to try "fn I(unused T:! type).F ..." we would find that the toolchain's generic-handling code does not handle unused correctly in either construction or comparison of eval blocks (or both). This is explicitly left as TODO, and I would prefer to not expand the scope of this PR further.

Copy link
Contributor Author

@burakemir burakemir Feb 18, 2026

Choose a reason for hiding this comment

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

To be very clear: the test is not failing for me, with the warning being present in the expected output. I propose to just leave that warning in.

Comment on lines 195 to 198
// CHECK:STDERR: nested_require_incomplete_interface.carbon:[[@LINE+4]]:6: warning: binding `T` unused [UnusedBinding]
// CHECK:STDERR: fn F(T:! X where .X1 = {}) {}
// CHECK:STDERR: ^
// CHECK:STDERR:
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add an unused marker 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.

Done.

@burakemir
Copy link
Contributor Author

Thanks for taking a look. It is not the case that I had a couple failing tests (wouldn't presubmit have caught this?), it is rather that everytime a test case gets added anywhere, it likely contains unused variables which are now diagnosed. This is one reason why I had to catch up the 150 commits with a strategy of rebase-in-stages before doing the merge.

@jonmeow
Copy link
Contributor

jonmeow commented Feb 19, 2026

Thanks for all your work here, I'll finish and resolve any remaining merge issues.

wouldn't presubmit have caught this?

Unfortunately conflicts prevent GitHub actions from running; the local pre-commit tooling doesn't run tests because we value it being fast.

@jonmeow jonmeow enabled auto-merge February 19, 2026 21:06
@jonmeow jonmeow added this pull request to the merge queue Feb 19, 2026
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 19, 2026
@jonmeow jonmeow added this pull request to the merge queue Feb 19, 2026
Merged via the queue into carbon-language:trunk with commit fdb188c Feb 20, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

Comments