diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-07-24 18:00:36 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-07-24 18:00:36 +0200 |
| commit | 720c6f19b7c11a31fe4f1efece12a8709c67b651 (patch) | |
| tree | 224b791d32a8ce7c281505b9872e75fe8f709ba9 /compiler/rustc_parse/src/errors.rs | |
| parent | 130d15e23e2f06e0d777ecdc078cc2b49fefb543 (diff) | |
| parent | 91af6b51223625ea5cd34d77861648ca19566deb (diff) | |
| download | rust-720c6f19b7c11a31fe4f1efece12a8709c67b651.tar.gz rust-720c6f19b7c11a31fe4f1efece12a8709c67b651.zip | |
Rollup merge of #127252 - fitzgen:edge-cases-for-bitwise-operations, r=m-ou-se
Add edge-case examples to `{count,leading,trailing}_{ones,zeros}` methods
Some architectures (i386) do not define a "count leading zeros" instruction, they define a "find first set bit" instruction (`bsf`) whose result is undefined when given zero (ie none of the bits are set). Of this family of bitwise operations, I always forget which of these things is potentially undefined for zero, and I'm also not 100% sure that Rust provides a hard guarantee for the results of these methods when given zero. So I figured there are others who have these same uncertainties, and it would be good to resolve them and answer the question via extending these doc examples/tests.
See https://en.wikipedia.org/wiki/Find_first_set#Hardware_support for more info on i386 and `bsf` on zero.
Diffstat (limited to 'compiler/rustc_parse/src/errors.rs')
0 files changed, 0 insertions, 0 deletions