Matthias Krüger [Fri, 20 May 2022 17:54:44 +0000 (19:54 +0200)]
Rollup merge of #97215 - AngelicosPhosphoros:add_hashtable_iteration_complexity_note, r=thomcc
Add complexity estimation of iterating over HashSet and HashMap
It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning.
I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results:
```
capacity - time
64 - 203.87 ns
256 - 351.78 ns
1024 - 607.87 ns
4096 - 965.82 ns
16384 - 3.1188 us
```
If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933).
Benchmarks code would be presented in PR related to this commit.
Matthias Krüger [Fri, 20 May 2022 17:54:42 +0000 (19:54 +0200)]
Rollup merge of #97203 - ehuss:rustc-summary-formatting, r=Dylan-DPC
Minor tweaks to rustc book summary formatting.
This includes a few minor tweaks to the summary/titles of chapters for the rustc book:
* Use a consistent chapter capitalization and hyphenation.
* Move "Codegen Options" underneath "Command-line Arguments". I feel like they are two closely related chapters, where codegen is just a subset of the total arguments.
* Move "Target Tier Policy" underneath "Platform Support". That chapter includes that policy for platform support, and thus I feel it is more closely related to that grouping.
Matthias Krüger [Fri, 20 May 2022 17:54:40 +0000 (19:54 +0200)]
Rollup merge of #97187 - ajtribick:patch-1, r=thomcc
Reverse condition in Vec::retain_mut doctest
I find that the doctest for `Vec::retain_mut` is easier to read and understand when the `if` block corresponds to the path that returns `true` and the `else` block returns `false`. Having the `if` block be the `false` path led me to stare at the example for somewhat longer than I probably had to.
Add complexity estimation of iterating over HashSet and HashMap
It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning.
I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results:
```
capacity - time
64 - 203.87 ns
256 - 351.78 ns
1024 - 607.87 ns
4096 - 965.82 ns
16384 - 3.1188 us
```
If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933).
Benchmarks code would be presented in PR related to this commit.
bors [Fri, 20 May 2022 13:18:37 +0000 (13:18 +0000)]
Auto merge of #97211 - GuillaumeGomez:rollup-jul7x7e, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #96565 (rustdoc: show implementations on `#[fundamental]` wrappers)
- #97179 (Add new lint to enforce whitespace after keywords)
- #97185 (interpret/validity: separately control checking numbers for being init and non-ptr)
- #97188 (Remove unneeded null pointer asserts in ptr2int casts)
- #97189 (Update .mailmap)
- #97192 (Say "last" instead of "rightmost" in the documentation for `std::str:rfind`)
Guillaume Gomez [Fri, 20 May 2022 12:03:06 +0000 (14:03 +0200)]
Rollup merge of #97192 - sunfishcode:sunfishcode/rightmost, r=thomcc
Say "last" instead of "rightmost" in the documentation for `std::str:rfind`
In the documentation comment for `std::str::rfind`, say "last" instead
of "rightmost" to describe the match that `rfind` finds. This follows the
spirit of #30459, for which `trim_left` and `trim_right` were replaced by
`trim_start` and `trim_end` to be more clear about how they work on
text which is displayed right-to-left.
Guillaume Gomez [Fri, 20 May 2022 12:03:04 +0000 (14:03 +0200)]
Rollup merge of #97188 - carbotaniuman:remove-null-assert, r=RalfJung
Remove unneeded null pointer asserts in ptr2int casts
This removes an assert that a pointer with address 0 has no provenance. This change is needed to support permissive provenance work in Miri, and seems justified by `ptr.with_addr(0)` working and a discussion on Zulip regarding LLVM semantics.
bors [Fri, 20 May 2022 03:27:01 +0000 (03:27 +0000)]
Auto merge of #97029 - eholk:drop-tracking-yielding-in-match-guard, r=nikomatsakis
generator_interior: Count match pattern bindings as borrowed for the whole guard expression
The test case `yielding-in-match-guard.rs` was failing with `-Zdrop-tracking` enabled. The reason is that the copy of a local (`y`) was not counted as a borrow in typeck, while MIR did consider this as borrowed.
The correct thing to do here is to count pattern bindings are borrowed for the whole guard. Instead, what we were doing is to record the type at the use site of the variable and check if the variable comes from a borrowed pattern. Due to the fix for #57017, we were considering too small of a scope for this variable, which meant it was not counted as borrowed.
Because we now unconditionally record the borrow, rather than only for bindings that are used, this PR is also able to remove a lot of the logic around match bindings that was there before.
bors [Fri, 20 May 2022 01:05:53 +0000 (01:05 +0000)]
Auto merge of #97027 - cuviper:yesalias-refcell, r=thomcc
Use pointers in `cell::{Ref,RefMut}` to avoid `noalias`
When `Ref` and `RefMut` were based on references, they would get LLVM `noalias` attributes that were incorrect, because that alias guarantee is only true until the guard drops. A `&RefCell` on the same value can get a new borrow that aliases the previous guard, possibly leading to miscompilation. Using `NonNull` pointers in `Ref` and `RefCell` avoids `noalias`.
Fixes the library side of #63787, but we still might want to explore language solutions there.
Dan Gohman [Thu, 19 May 2022 22:26:34 +0000 (15:26 -0700)]
Say "last" instead of "rightmost" in the documentation for `std::str::rfind`.
In the documentation comment for `std::str::rfind`, say "last" instead
of "rightmost" to describe the match that `rfind` finds. This follows the
spirit of #30459, for which `trim_left` and `trim_right` were replaced by
`trim_start` and `trim_end` to be more clear about how they work on
text which is displayed right-to-left.
bors [Thu, 19 May 2022 13:08:51 +0000 (13:08 +0000)]
Auto merge of #97024 - lcnr:simplify_type-sus, r=<try>
`simplify_type` improvements and cursed docs
the existing `TreatParams` enum pretty much mixes everything up. Not sure why this looked right to me in #94057
This also includes two changes which impact perf:
- `ty::Projection` with inference vars shouldn't be treated as a rigid type, even if fully normalized
- `ty::Placeholder` only unifies with itself, so actually return `Some` for them
bors [Thu, 19 May 2022 04:04:40 +0000 (04:04 +0000)]
Auto merge of #97033 - nbdd0121:unwind3, r=Amanieu
Remove libstd's calls to `C-unwind` foreign functions
Remove all libstd and its dependencies' usage of `extern "C-unwind"`.
This is a prerequiste of a WIP PR which will forbid libraries calling `extern "C-unwind"` functions to be compiled in `-Cpanic=unwind` and linked against `panic_abort` (this restriction is necessary to address soundness bug #96926).
Cargo will ensure all crates are compiled with the same `-Cpanic` but the std is only compiled `-Cpanic=unwind` but needs the ability to be linked into `-Cpanic=abort`.
Currently there are two places where `C-unwind` is used in libstd:
* `__rust_start_panic` is used for interfacing to the panic runtime. This could be `extern "Rust"`
* `_{rdl,rg}_oom`: a shim `__rust_alloc_error_handler` will be generated by codegen to call into one of these; they can also be `extern "Rust"` (in fact, the generated shim is used as `extern "Rust"`, so I am not even sure why these are not, probably because they used to `extern "C"` and was changed to `extern "C-unwind"` when we allow alloc error hooks to unwind, but they really should just be using Rust ABI).
For dependencies, there is only one `extern "C-unwind"` function call, in `unwind` crate. This can be expressed as a re-export.
More dicussions can be seen in the Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/soundness.20in.20mixed.20panic.20mode
bors [Thu, 19 May 2022 01:41:07 +0000 (01:41 +0000)]
Auto merge of #97159 - JohnTitor:rollup-ibl51vw, r=JohnTitor
Rollup of 6 pull requests
Successful merges:
- #96866 (Switch CI bucket uploads to intelligent tiering)
- #97062 (Couple of refactorings to cg_ssa::base::codegen_crate)
- #97127 (Revert "Auto merge of #96441 - ChrisDenton:sync-pipes, r=m-ou-se")
- #97131 (Improve println! documentation)
- #97139 (Move some settings DOM generation out of JS)
- #97152 (Update cargo)
Yuki Okushi [Wed, 18 May 2022 23:22:45 +0000 (08:22 +0900)]
Rollup merge of #97152 - ehuss:update-cargo, r=ehuss
Update cargo
3 commits in 3f052d8eed98c6a24f8b332fb2e6e6249d12d8c1..a4c1cd0eb6b18082a7e693f5a665548fe1534be4
2022-05-12 15:19:04 +0000 to 2022-05-18 01:52:07 +0000
- Add notes about pre-stabilization to contributor unstable docs (rust-lang/cargo#10675)
- reference: Update syntax supported by `rustc-link-lib` (rust-lang/cargo#10674)
- Correct the release dates for 1.61 and 1.62 (rust-lang/cargo#10665)
Yuki Okushi [Wed, 18 May 2022 23:22:44 +0000 (08:22 +0900)]
Rollup merge of #97139 - GuillaumeGomez:move-dom-settings-generation, r=notriddle
Move some settings DOM generation out of JS
The first commit reduce the JS size a bit by moving some DOM content generation into the HTML file directly.
The second commit is an update of the `browser-ui-test` version which improves `wait-for-*` command (if the element doesn't exist, it'll wait for it instead of failing).
Partially addresses https://github.com/rust-lang/rust/issues/97124, but not marking as fixed as we're still pending on a beta backport (for 1.62, which is happening in https://github.com/rust-lang/rust/pull/97088).
Yuki Okushi [Wed, 18 May 2022 23:22:41 +0000 (08:22 +0900)]
Rollup merge of #96866 - Mark-Simulacrum:intelligent-tiering-ci, r=pietroalbini
Switch CI bucket uploads to intelligent tiering
We currently upload approximately 166 GB/day into this bucket (estimate based on
duration of storage and total current size). My estimate is that this change
should decrease our costs (which are currently in credits) and is in the worst
case (if all objects are brought into hot storage due to unanticipated frequent
access) only going to add an additional ~$4 to the monthly bill. If access is
rare (as expected) to most objects then we expect to save approximately
~$350/month (after this change takes full effect in ~168 days).
`@Amanieu,` I didn't switch inline asms to use `DefKind::InlineAsm`, as I see little value doing that; given that no type inference is needed, it will only make typecking slower and more complex but will have no real gains. I did switch them to follow the same code path as inline asm during symbol resolution, though.
The `error: unconstrained generic constant` you mentioned in #76001 is due to the fact that `to_const` will actually add a wfness obligation to the constant, which we don't need for `asm_const`, so I have that removed.
bors [Wed, 18 May 2022 12:45:44 +0000 (12:45 +0000)]
Auto merge of #96867 - michaelwoerister:path-prefix-fixes-2, r=davidtwco
--remap-path-prefix: Fix duplicated path components in debuginfo
This PR fixes an issue with `--remap-path-prefix` where path components could appear twice in the remapped version of the path (e.g. https://github.com/rust-lang/rust/issues/78479). The underlying problem was that `--remap-path-prefix` is often used to map an absolute path to something that looks like a relative path, e.g.:
and relative paths in debuginfo are interpreted as being relative to the compilation directory. So if Cargo invokes the compiler with `/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823/some_crate-0.1.0/src/lib.rs` as input and `/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823/some_crate-0.1.0` as the compiler's working directory, then debuginfo will state that the working directory was `crates.io/some_crate-0.1.0` and the file is question was `crates.io/some_crate-0.1.0/src/lib.rs`, which combined gives the path:
With this PR the compiler will detect this situation and set up debuginfo in LLVM in a way that makes it strip the duplicated path components when emitting DWARF.
The PR also extracts the logic for making remapped paths absolute into a common helper function that is now used by debuginfo too (instead of just during crate metadata generation).
bors [Wed, 18 May 2022 09:53:01 +0000 (09:53 +0000)]
Auto merge of #97110 - Kobzol:pgo-pid-in-profile, r=lqd
Add PID to PGO profile data filename
After experimenting with PGO, it looks like the generated profile data files can be sometimes overwritten if there is a race condition, because multiple `rustc` processes are usually invoked in parallel by `cargo`. Adding the PID to the resulting profile filename pattern makes sure that the profiles will be stored in separate files.
This generates ~20 GiB more space on disk on the CI run, but that seems harmless (?). Merging the profiles is not a bottleneck, the perf. run took the same amount of time as usually (~1h 24m).
Dylan DPC [Wed, 18 May 2022 06:41:18 +0000 (08:41 +0200)]
Rollup merge of #97123 - ricked-twice:issue-96223-clean-fix, r=jackh726
Clean fix for #96223
Okay, so here we are (hopefully) :+1:
Closes #96223
Thanks a lot to `@jackh726` for your help and explanation :pray:
- Modified `InferCtxt::mk_trait_obligation_with_new_self_ty` to take as argument a `Binder<(TraitPredicate, Ty)>` instead of a `Binder<TraitPredicate>` and a separate `Ty` with no bound vars.
- Modified all call places to avoid calling `Binder::no_bounds_var` or `Binder::skip_binder` when it is not safe.
Dylan DPC [Wed, 18 May 2022 06:41:16 +0000 (08:41 +0200)]
Rollup merge of #96917 - marti4d:master, r=ChrisDenton
Make HashMap fall back to RtlGenRandom if BCryptGenRandom fails
With PR #84096, Rust `std::collections::hash_map::RandomState` changed from using `RtlGenRandom()` ([msdn](https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom)) to `BCryptGenRandom()` ([msdn](https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom)) as its source of secure randomness after much discussion ([here](https://github.com/rust-random/getrandom/issues/65#issuecomment-753634074), among other places).
Unfortunately, after that PR landed, Mozilla Firefox started experiencing fairly-rare crashes during startup while attempting to initialize the `env_logger` crate. ([docs for env_logger](https://docs.rs/env_logger/latest/env_logger/)) The root issue is that on some machines, `BCryptGenRandom()` will fail with an `Access is denied. (os error 5)` error message. ([Bugzilla issue 1754490](https://bugzilla.mozilla.org/show_bug.cgi?id=1754490)) (Discussion in issue #94098)
Note that this is happening upon startup of Firefox's unsandboxed Main Process, so this behavior is different and separate from previous issues ([like this](https://bugzilla.mozilla.org/show_bug.cgi?id=1746254)) where BCrypt DLLs were blocked by process sandboxing. In the case of sandboxing, we knew we were doing something abnormal and expected that we'd have to resort to abnormal measures to make it work.
However, in this case we are in a regular unsandboxed process just trying to initialize `env_logger` and getting a panic. We suspect that this may be caused by a virus scanner or some other security software blocking the loading of the BCrypt DLLs, but we're not completely sure as we haven't been able to replicate locally.
It is also possible that Firefox is not the only software affected by this; we just may be one of the pieces of Rust software that has the telemetry and crash reporting necessary to catch it.
I have read some of the historical discussion around using `BCryptGenRandom()` in Rust code, and I respect the decision that was made and agree that it was a good course of action, so I'm not trying to open a discussion about a return to `RtlGenRandom()`. Instead, I'd like to suggest that perhaps we use `RtlGenRandom()` as a "fallback RNG" in the case that BCrypt doesn't work.
This pull request implements this fallback behavior. I believe this would improve the robustness of this essential data structure within the standard library, and I see only 2 potential drawbacks:
1. Slight added overhead: It should be quite minimal though. The first call to `sys::rand::hashmap_random_keys()` will incur a bit of initialization overhead, and every call after will incur roughly 2 non-atomic global reads and 2 easily predictable branches. Both should be negligible compared to the actual cost of generating secure random numbers
2. `RtlGenRandom()` is deprecated by Microsoft: Technically true, but as mentioned in [this comment on GoLang](https://github.com/golang/go/issues/33542#issuecomment-626124873), this API is ubiquitous in Windows software and actually removing it would break lots of things. Also, Firefox uses it already in [our C++ code](https://searchfox.org/mozilla-central/rev/5f88c1d6977e03e22d3420d0cdf8ad0113c2eb31/mfbt/RandomNum.cpp#25), and [Chromium uses it in their code as well](https://source.chromium.org/chromium/chromium/src/+/main:base/rand_util_win.cc) (which transitively means that Microsoft uses it in their own web browser, Edge). If there did come a time when Microsoft truly removes this API, it should be easy enough for Rust to simply remove the fallback in the code I've added here
Dylan DPC [Wed, 18 May 2022 06:41:15 +0000 (08:41 +0200)]
Rollup merge of #96378 - compiler-errors:trait-upcast-error, r=nagisa
Mention traits and types involved in unstable trait upcasting
Fixes #95972 by printing the traits being upcasted and the types being coerced that cause that upcasting...
---
the poor span mentioned in the original issue has nothing to do with trait upcasting diagnostic here...
> The original example I had that made me run into this issue had an even longer expression there (multiple chained
iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed".
I don't think I can solve that issue in general without fixing the ObligationCauseCode and span that gets passed into Coerce.
Dylan DPC [Wed, 18 May 2022 06:41:13 +0000 (08:41 +0200)]
Rollup merge of #94639 - compiler-errors:rval-mutref, r=wesleywiser
Suggest dereferencing non-lval mutable reference on assignment
1. Adds deref suggestions for LHS of assignment (or assign-binop) when it implements `DerefMut`
2. Fixes missing deref suggestions for LHS when it isn't a place expr