about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp
diff options
context:
space:
mode:
authorYuki Okushi <jtitor@2k36.org>2021-06-08 13:26:29 +0900
committerGitHub <noreply@github.com>2021-06-08 13:26:29 +0900
commit2a23af63418a3b7c069ab414e3477184893eabcb (patch)
tree7fadb2213b5a0bbde51dbc2d70b20e76215efc29 /compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp
parent3502bff9002cc36b7cb3eeb58260e593c5d8af7c (diff)
parentfddf012177671110caa96c4d9036199a0b91b8e7 (diff)
downloadrust-2a23af63418a3b7c069ab414e3477184893eabcb.tar.gz
rust-2a23af63418a3b7c069ab414e3477184893eabcb.zip
Rollup merge of #85985 - Lionelf329:master, r=joshtriplett
Clarify documentation of slice sorting methods

After reading about [this](https://polkadot.network/a-polkadot-postmortem-24-05-2021/), I realized that although the documentation of these methods is not ambiguous in its current state, it is very easy to read it and erroneously assume that their exact behaviour can be relied upon to be deterministic. Although the docs make no guarantees about which index is returned when there are multiple matches, being more explicit about when and how their determinism can be relied upon should help prevent people from making this mistake in the future.

r? ``@steveklabnik``
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions