about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/errors.rs
diff options
context:
space:
mode:
authorNick Fitzgerald <fitzgen@gmail.com>2024-07-02 15:00:09 -0700
committerNick Fitzgerald <fitzgen@gmail.com>2024-07-02 15:00:09 -0700
commit91af6b51223625ea5cd34d77861648ca19566deb (patch)
tree0f359e3f605b1edf13b9494b2dcd11aefeba0447 /compiler/rustc_parse/src/errors.rs
parent49ff3909fbd499218a28a31d3a33e88365496a55 (diff)
downloadrust-91af6b51223625ea5cd34d77861648ca19566deb.tar.gz
rust-91af6b51223625ea5cd34d77861648ca19566deb.zip
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