-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Improve rustc_mir_build::matches
docs
#81364
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
camelid
commented
Jan 25, 2021
- Fix typos
- Add more information
- General cleanup
- Fix typos - Add more information - General cleanup
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
@@ -1214,31 +1225,35 @@ impl<'a, 'tcx> Builder<'a, 'tcx> { | |||
/// This is the most subtle part of the matching algorithm. At | |||
/// this point, the input candidates have been fully simplified, | |||
/// and so we know that all remaining match-pairs require some | |||
/// sort of test. To decide what test to do, we take the highest | |||
/// sort of test. To decide what test to perform, we take the highest | |||
/// priority candidate (last one in the list) and extract the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment is wrong, as in the code itself we see the highest priority candidate being referred to as the first in the list:
rust/compiler/rustc_mir_build/src/build/matches/mod.rs
Lines 1334 to 1335 in 2ea320a
// extract the match-pair from the highest priority candidate | |
let match_pair = &candidates.first().unwrap().match_pairs[0]; |
This also seems to match all other references to the sorting order.
This looks good to me; sorry for the delay. r=me after correcting the comment about the order that you highlighted. |
The highest-priority item is the *first* in the list, not the last. See [this code][1] for more. [this code]: https://github.com/rust-lang/rust/blob/0e63af5da3400ace48a0345117980473fd21ad73/compiler/rustc_mir_build/src/build/matches/mod.rs#L1334-L1335
@bors r=varkor My first |
📌 Commit 8b52cdc has been approved by |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 8b52cdc has been approved by ``` |
Weird... Maybe I can't put stuff after the |
@bors r=varkor |
📌 Commit 8b52cdc has been approved by |
… r=varkor Improve `rustc_mir_build::matches` docs - Fix typos - Add more information - General cleanup
… r=varkor Improve `rustc_mir_build::matches` docs - Fix typos - Add more information - General cleanup
…as-schievink Rollup of 12 pull requests Successful merges: - rust-lang#78641 (Let io::copy reuse BufWriter buffers) - rust-lang#79291 (Add error message for private fn) - rust-lang#81364 (Improve `rustc_mir_build::matches` docs) - rust-lang#81387 (Move some tests to more reasonable directories - 3) - rust-lang#81463 (Rename NLL* to Nll* accordingly to C-CASE) - rust-lang#81504 (Suggest accessing field when appropriate) - rust-lang#81529 (Fix invalid camel case suggestion involving unicode idents) - rust-lang#81536 (Indicate both start and end of pass RSS in time-passes output) - rust-lang#81592 (Rustdoc UI fixes) - rust-lang#81594 (Avoid building LLVM just for llvm-dwp) - rust-lang#81598 (Fix calling convention for CRT startup) - rust-lang#81618 (Sync rustc_codegen_cranelift) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup