-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve rustc_mir_build::matches
docs
#81364
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