document Closure capture precision#698
Conversation
e3ed8e9 to
7be2ad5
Compare
|
all addressed but #698 (comment) |
There was a problem hiding this comment.
I will probably need to read Capture precision to ensure that no rules have been omitted.
| - `Const blocks are no longer evaluated to determine if expressions involving fallible operations can implicitly be constant-promoted <https://github.com/rust-lang/rust/pull/150557>`_ | ||
| - `Make operational semantics of pattern matching independent of crate and module <https://github.com/rust-lang/rust/pull/150681>`_ | ||
|
|
||
| Changed paragraphs: |
There was a problem hiding this comment.
The paragraph-ID list itself looks fine, but this changelog attribution still seems too broad.
The changed capture-mode paragraphs fit rust-lang/rust#150681, but the new capture-precision block spans multiple sources: some items align with the later pattern/discriminant work in rust-lang/rust#138961 and rust-lang/reference#1837, while others are pre-existing Reference behavior now being documented here.
Could this entry be split, or reworded so #150681 is not presented as introducing the whole block? The note that these paragraphs mostly document behavior that existed before this release already points in that direction.
Support:
There was a problem hiding this comment.
I can go find where each behavior was added, but am not sure it's worth the time
maybe a good compromise is having a different heading, like "Pre-existing behavior before 1.95", or just "FLS maintenance"
There was a problem hiding this comment.
@tshepang So far we have used the following headings:
FLS fixes/improvements
FLS correctionsI think those should be changed to "FLS maintenance" (as it is more general), and you should use that heading to split the pre-release changes.
This comment has been minimized.
This comment has been minimized.
dcd9707 to
550f10d
Compare
This comment has been minimized.
This comment has been minimized.
Just to clarify, after reading the Reference's Capture precision, I think "place" is indeed the proper term. |
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
…erload the term) Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
Also, sort by alphabet
In an FLS call, we decided that it's not important after all... my thinking is that mentioning a read is not exactly relevant, as FLS is not a place to explain mechanics of rustc. It should be enough to only explain surface behavior, and not why that behavior is so. This reverts commit a3d7be4.
529319e to
c14483e
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
rebased due to divergence from |
hristian took over, and review now handled
This captures some gaps FLS has compared to Reference, and the content is adjusted from Closure capture precision section.