Use .name_str() to format primitive types in error messages
This pull request fixes#84976. The problem described there is caused by this code
506e75cbf8/compiler/rustc_middle/src/ty/error.rs (L161-L166)
using `Debug` formatting (`{:?}`), while the proper solution is to call `name_str()` of `ty::IntTy`, `ty::UintTy` and `ty::FloatTy`, respectively.
Change param name (k to key and v to value) in std::env module
1. When I was reading code the ide displayed `k` and `v`, so I
thought it would be better to show key and value?
2. I noticed var method already uses `key` instead of `k` so it
is more consistent to use `key` instead of `k`?
Thanks
rustdoc: remove explicit boolean comparisons.
For boolean variables it's shorter and more readable to check the value directly, or negate it with `!`.
In a couple of cases I reordered an if/else pair because it made the initial `if` statement simpler.
An example of a style guide recommending this: https://airbnb.io/javascript/#comparison--shortcuts
r? `@GuillaumeGomez`
In rustdoc's main.js, we had an onclick handler for the whole document
that would dispatch to handlers for various elements. This change
attaches the handlers to the elements that trigger them, instead.
This simplfies the code and avoids reimplementing the browser's bubbling
functionality.
As part of this change, change from a class to an id for help button.
Move the handlers and associated code for highlighting source lines into
source-script.js (and factor out a shared regex).
BTree: no longer copy keys and values before dropping them
When dropping BTreeMap or BTreeSet instances, keys-value pairs are up to now each copied and then dropped, at least according to source code. This is because the code for dropping and for iterators is shared.
This PR postpones the treatment of doomed key-value pairs from the intermediate functions `deallocating_next`(`_back`) to the last minute, so the we can drop the keys and values in place. According to the library/alloc benchmarks, this does make a difference, (and a positive difference with an `#[inline]` on `drop_key_val`). It does not change anything for #81444 though.
r? `@Mark-Simulacrum`
For boolean variables it's shorter and more readable to check the value
directly, or negate it with `!`.
In a couple of cases I reordered an if/else pair because it made the
initial `if` statement simpler.
Removed unused isType parameter from two functions.
At first you might think "why not just click through to the aliased
type?", but if a type alias instantiates all of the generic parameters
of the aliased type, then it can show layout info even though the
aliased type cannot (because we can't compute the layout of a generic
type). So I think it's still useful to show layout info for type
aliases.
