Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

What is considered a "read"?

Open
  • Is something wrong?
#2,151 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@ehuss is already working on this.

Since Feb 20, 2026.

  • #2186 by @ehuss — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
documentation

Research direction

Start with the referenced functions in compiler/rustc_middle/src/hir/mod.rs and compiler/rustc_hir/src/hir.rs, then read Reference PRs 1837 and 2067 plus the linked Rust PRs. Compare the rules for divergence, closure capture, patterns, and discriminant reads; done means the Reference clearly documents the applicable definitions and distinctions.

Written by the indexing model from the issue text.

Description

A-divergence

https://github.com/rust-lang/reference/pull/2067 added a chapter on divergence with the rule expr.block.diverging that says:

A block is considered to be diverging if all reachable control flow paths contain a diverging expression, unless that expression is a place expression that is not read from.

But I don't think the reference has a clear definition of what it means to "read" from a place expression. What are the rules for what is considered a "read"? Is this unique to divergence checking?

Closure capture has has a bunch of rules of what it considers a "read" (or more often, what is not considered a read). I believe there are slight differences for various reasons. For example, a reference does not seem to be read for the purpose of divergence, but for the purpose of closure capture it does seem to be considered a read and is captured. There are various things around fake reads that I have forgotten how they work. I don't know if the rules are fundamentally different, or if there is some commonality.

I'll take a wild guess as to what is not considered a read based on expr_guaranteed_to_constitute_read_for_never:

  • A borrow expression.
  • The left-hand side of an assignment.
  • The base of a field projection that doesn't itself constitute a read.
  • The scrutinee of a match expression where at least one arm's pattern does not force a read.
  • The initializer of a let statement where the pattern does not force a read.
  • The scrutinee of a let condition where the pattern does not force a read.

(Of course non-place is always "read".)

I don't know if there are other considerations or how things like discriminants get involved.

It could also include details on which patterns force a read, which I think is is_guaranteed_to_constitute_read_for_never, which is more or less the following aren't reads:

  • _ wildcard
  • | or patterns where at least one alternative doesn't force a read

See also some recent things:

cc @jackh726

Dominant language
Rust
Stars
1.6k
Forks
609
Avg merge
1d 4h
Merged PRs (30d)
7

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-lang/reference

All issues in rust-lang/reference

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.