Replace push loops with extend() where possible
Or set the vector capacity where I couldn't do it.
According to my [simple benchmark](https://gist.github.com/ljedrz/568e97621b749849684c1da71c27dceb) `extend`ing a vector can be over **10 times** faster than `push`ing to it in a loop:
10 elements (6.1 times faster):
```
test bench_extension ... bench: 75 ns/iter (+/- 23)
test bench_push_loop ... bench: 458 ns/iter (+/- 142)
```
100 elements (11.12 times faster):
```
test bench_extension ... bench: 87 ns/iter (+/- 26)
test bench_push_loop ... bench: 968 ns/iter (+/- 3,528)
```
1000 elements (11.04 times faster):
```
test bench_extension ... bench: 311 ns/iter (+/- 9)
test bench_push_loop ... bench: 3,436 ns/iter (+/- 233)
```
Seems like a good idea to use `extend` as much as possible.
Do a basic sanity check for all constant values
## Motivation and high level overview
There has been some back and forth in this PR between @RalfJung and me in here about the motivation for this change and the stance it takes on unsafe coding guidelines.
The initial implementation ran its checks on every value read (so `*x`, `y = x`, ...). In unsafe code that isn't reasonable, because we might be invalidating invariants for a short time in order to build up a proper value.
The current implementation is a lint that runs its checks statics and constants. There is no need to check array lengths and enum variants, because it's a hard error to end up with anything but a number, and that one even has to have the required bits to be defined.
## What checks are done?
* Some type related checks
* `char` needs to be a correct unicode character as defined by `char::from_u32`
* A reference to a ZST must have the correct alignment (and be nonzero)
* A reference to anything is dereferenced and its value is checked
* Layout checks use the information from `ty::Layout` to check
* all fields of structs
* all elements of arrays
* enum discriminants
* the fields of an enum variant (the variant is decided by the discriminant)
* whether any union field succeeds in being checked (if none match the memory pattern, the check fails)
* if the value is in the range described by the layout (e.g. for `NonZero*` types)
Changing the layout of a type will thus automatically cause the checks to check for the new layout.
fixes#51330fixes#51471
cc @RalfJung
r? @eddyb
rustdoc: rework how default passes are chosen
This is a refactor that changes how we select default passes, and changes the set of passes used for `--document-private-items`. It's groundwork for a bigger refactor i want to do.
The major changes:
* There are now two sets of "default passes": one set for "no flags given" and one for "document private items".
* These sets can be selected by a new `DefaultPassOption` enum, which is selected from based on the presence of `--no-defaults` or `--document-private-items` CLI flags, or their associated crate attributes.
* When printing the list of passes, we also print the list of passes for `--document-private-items` in addition to the "default defaults".
* I added `propagate-doc-cfg` and `strip-priv-imports` to the "document private items" set. The former is to ensure items are properly tagged with the full set of cfg flags even when "document private items" is active. The latter is based on feedback and personal experience navigating the `rustc` docs, which use that flag. `strip-priv-imports` only removes non-pub `use` statements, so it should be harmless from a documentation standpoint to remove those items from "private items" documentation.
Add the -Zcrate-attr=foo unstable rustc option
This PR adds a new unstable option to `rustc`: `-Zcrate-attr=foo`. The option can be used to inject crate-level attributes from the CLI, and it's meant to be used by tools like Crater that needs to add their own attributes to a crate without changing the source code.
The exact reason I need this is to implement "edition runs" in Crater: we need to add the preview feature flag to every crate, and editing the crates' source code on the fly might produce unexpected results, while a compiler flag is more reliable.
cc https://github.com/rust-lang-nursery/crater/issues/282 @Mark-Simulacrum
do not overwrite child def-id in place but rather remove/insert
When inserting a node N into the tree of impls, we sometimes find than an existing node C should be replaced with N. We used to overwrite C in place with the new def-id N -- but since the lists of def-ids are separated by simplified type, that could lead to N being inserted in the wrong place. This meant we might miss conflicts. We are now not trying to be so smart -- we remove C and then add N later.
Fixes#52050
r? @aturon -- do you still remember this code at all? :)
Rollup of 11 pull requests
Successful merges:
- #52702 (Suggest fix when encountering different mutability from impl to trait)
- #52703 (Improve a few vectors - calculate capacity or build from iterators)
- #52740 (Suggest underscore when using dashes in crate namet push fork)
- #52759 (Impl Send & Sync for JoinHandle)
- #52760 (rustc_metadata: test loading atoi instead of cos)
- #52763 (Omit the vendor component in Fuchsia triple)
- #52765 (Remove unused "-Zenable_nonzeroing_move_hints" flag)
- #52769 (Incorporate a stray test)
- #52777 (Fix doc comment for 'ptr::copy_to' method)
- #52779 (revert accidental atty downgrade)
- #52781 (Use a slice where a vector is not necessary)
Failed merges:
r? @ghost
