Matthias Krüger [Sun, 16 Jan 2022 15:58:18 +0000 (16:58 +0100)]
Rollup merge of #92746 - estebank:question-mark-in-type, r=davidtwco
Parse `Ty?` as `Option<Ty>` and provide structured suggestion
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
Matthias Krüger [Sun, 16 Jan 2022 15:58:17 +0000 (16:58 +0100)]
Rollup merge of #92710 - jackh726:issue-92280, r=nikomatsakis
Include Projections when elaborating TypeOutlives
Fixes #92280
In `Elaborator`, we elaborate that `Foo<<Bar as Baz>::Assoc>: 'a` -> `<Bar as Baz>::Assoc: 'a`. This is the same rule that would be applied to any other `Param`. If there are escaping vars, we continue to do nothing.
Matthias Krüger [Sun, 16 Jan 2022 15:58:16 +0000 (16:58 +0100)]
Rollup merge of #92706 - umanwizard:btree, r=dtolnay
Clarify explicitly that BTree{Map,Set} are ordered.
One of the main reasons one would want to use a BTree{Map,Set} rather than a Hash{Map,Set} is because they maintain their keys in sorted order; but this was never explicitly stated in the top-level docs (it was only indirectly alluded to there, and stated explicitly in the docs for `iter`, `values`, etc.)
This PR states the ordering guarantee more prominently.
Matthias Krüger [Sun, 16 Jan 2022 15:58:14 +0000 (16:58 +0100)]
Rollup merge of #92619 - Alexendoo:macro-diagnostic-items, r=matthewjasper
Add diagnostic items for macros
For use in Clippy, it adds diagnostic items to all the stable public macros
Clippy has lints that look for almost all of these (currently by name or path), but there are a few that aren't currently part of any lint, I could remove those if it's preferred to add them as needed rather than ahead of time
bors [Sun, 16 Jan 2022 14:25:25 +0000 (14:25 +0000)]
Auto merge of #92245 - petrochenkov:cmrval, r=nagisa
rustc_metadata: Switch all decoder methods from vectors to iterators
To avoid allocations in some cases.
Also remove unnecessary `is_proc_macro_crate` checks from decoder, currently the general strategy is to shift all the work to the encoder and assume that all the encoded data is correct and can be decoded unconditionally in the decoder.
reverts #87280 except for some of the changes around `ty::Unevaluated` having a visitor and a generic for promoted
why revert: <https://github.com/rust-lang/rust/pull/92805#issuecomment-1010736049>
... and indirectly, this updates all of crossbeam-* to their latest versions.
Fixes #92677 by removing crossbeam-queue, but there's still a lingering question about how tidy discovers "runtime" dependencies. None of this is truly in the standard library's dependency tree at all.
David Tolnay [Sun, 16 Jan 2022 03:28:19 +0000 (19:28 -0800)]
Tweak btree iterator wording to not use 'yield'
Yield means something else in the context of generators, which are
sufficiently close to iterators that it's better to avoid the
terminology collision here.
bors [Sun, 16 Jan 2022 02:18:42 +0000 (02:18 +0000)]
Auto merge of #92598 - Badel2:panic-update-hook, r=yaahc
Implement `panic::update_hook`
Add a new function `panic::update_hook` to allow creating panic hooks that forward the call to the previously set panic hook, without race conditions. It works by taking a closure that transforms the old panic hook into a new one, while ensuring that during the execution of the closure no other thread can modify the panic hook. This is a small function so I hope it can be discussed here without a formal RFC, however if you prefer I can write one.
This is a common pattern in libraries that need to do something in case of panic: log panic to a file, record code coverage, send panic message to a monitoring service, print custom message with link to github to open a new issue, etc. However it is impossible to avoid race conditions with the current API, because two threads can execute in this order:
* Thread A calls `panic::take_hook()`
* Thread B calls `panic::take_hook()`
* Thread A calls `panic::set_hook()`
* Thread B calls `panic::set_hook()`
And the result is that the original panic hook has been lost, as well as the panic hook set by thread A. The resulting panic hook will be the one set by thread B, which forwards to the default panic hook. This is not considered a big issue because the panic handler setup is usually run during initialization code, probably before spawning any other threads.
Using the new `panic::update_hook` function, this race condition is impossible, and the result will be either `A, B, original` or `B, A, original`.
I found one real world use case here: https://github.com/dtolnay/proc-macro2/blob/988cf403e741aadfd5340bbf67e35e1062a526aa/src/detection.rs#L32 the workaround is to detect the race condition and panic in that case.
The pattern of `take_hook` + `set_hook` is very common, you can see some examples in this pull request, so I think it's natural to have a function that combines them both. Also using `update_hook` instead of `take_hook` + `set_hook` reduces the number of calls to `HOOK_LOCK.write()` from 2 to 1, but I don't expect this to make any difference in performance.
### Unresolved questions:
* `panic::update_hook` takes a closure, if that closure panics the error message is "panicked while processing panic" which is not nice. This is a consequence of holding the `HOOK_LOCK` while executing the closure. Could be avoided using `catch_unwind`?
* Reimplement `panic::set_hook` as `panic::update_hook(|_prev| hook)`?
bors [Sat, 15 Jan 2022 14:43:45 +0000 (14:43 +0000)]
Auto merge of #92441 - cjgillot:resolve-trait-impl-item, r=matthewjasper
Link impl items to corresponding trait items in late resolver.
Hygienically linking trait impl items to declarations in the trait can be done directly by the late resolver. In fact, it is already done to diagnose unknown items.
This PR uses this resolution work and stores the `DefId` of the trait item in the HIR. This avoids having to do this resolution manually later.
r? `@matthewjasper`
Related to #90639. The added `trait_item_id` field can be moved to `ImplItemRef` to be used directly by your PR.
bors [Sat, 15 Jan 2022 10:57:03 +0000 (10:57 +0000)]
Auto merge of #92927 - matthiaskrgr:rollup-pgzwfcm, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #92747 (Simplification of BigNum::bit_length)
- #92767 (Use the new language identifier for Rust in the PDB debug format)
- #92775 (Inline std::os::unix::ffi::OsStringExt methods)
- #92863 (Remove `&mut` from `io::read_to_string` signature)
- #92865 (Ignore static lifetimes for GATs outlives lint)
- #92873 (Generate more precise generator names)
- #92879 (Add Sync bound to allocator parameter in vec::IntoIter)
- #92892 (Do not fail evaluation in const blocks)
Matthias Krüger [Sat, 15 Jan 2022 10:28:27 +0000 (11:28 +0100)]
Rollup merge of #92879 - compiler-errors:into_iter_unsound, r=dtolnay
Add Sync bound to allocator parameter in vec::IntoIter
The `A: Sync` bound was forgotten in https://github.com/rust-lang/rust/commit/8725e4c33749b23f260b2fc46e090c3792b6f97e#diff-b78c3ab6d37f4ede32195707528f8a76c49d4557cc9d3a7a09417b5157729b9fR3132
Similar `unsafe impl Sync` in that commit _do_ include the `A: Sync` bound (and around the alloc lib), so I think this was just an honest mistake.
Here's an example of the unsoundness: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=16cbfeff7c934ae72ab632c1476fdd8b
`@steffahn` found this, I'm just putting up the fix cause nobody else did :^)
Matthias Krüger [Sat, 15 Jan 2022 10:28:26 +0000 (11:28 +0100)]
Rollup merge of #92873 - eholk:async-symbol-names, r=tmandry
Generate more precise generator names
Currently all generators are named with a `generator$N` suffix, regardless of where they come from. This means an `async fn` shows up as a generator in stack traces, which can be surprising to async programmers since they should not need to know that async functions are implementated using generators.
This change generators a different name depending on the generator kind, allowing us to tell whether the generator is the result of an async block, an async closure, an async fn, or a plain generator.
r? `@tmandry`
cc `@michaelwoerister` `@wesleywiser` `@dpaoliello`
Matthias Krüger [Sat, 15 Jan 2022 10:28:24 +0000 (11:28 +0100)]
Rollup merge of #92863 - camelid:read_to_string-rm-mut, r=m-ou-se
Remove `&mut` from `io::read_to_string` signature
``@m-ou-se`` [realized][1] that because `Read` is implemented for `&mut impl
Read`, there's no need to take `&mut` in `io::read_to_string`.
Removing the `&mut` from the signature allows users to remove the `&mut`
from their calls (and thus pass an owned reader) if they don't use the
reader later.
bors [Sat, 15 Jan 2022 04:24:13 +0000 (04:24 +0000)]
Auto merge of #92915 - matthiaskrgr:rollup-pxxk8jp, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #92191 (Prefer projection candidates instead of param_env candidates for Sized predicates)
- #92382 (Extend const_convert to rest of blanket core::convert impls)
- #92625 (Add `#[track_caller]` to `mirbug`)
- #92684 (Export `tcp::IntoIncoming`)
- #92743 (Use pre-interned symbols in a couple of places)
- #92838 (Clean up some links in RELEASES)
- #92868 (librustdoc: Address some clippy lints)
- #92875 (Make `opt_const_param_of` work in the presence of `GenericArg::Infer`)
- #92891 (Add myself to .mailmap)
Matthias Krüger [Sat, 15 Jan 2022 01:25:20 +0000 (02:25 +0100)]
Rollup merge of #92875 - BoxyUwU:infer_arg_opt_const_param_of, r=lcnr
Make `opt_const_param_of` work in the presence of `GenericArg::Infer`
highly recommend viewing the first and second commits on their own rather than looking at file changes :rofl:
Because we filtered args down to just const args we would ignore `GenericArg::Infer` which made us get a `arg_index` which was wrong by however many const `GenericArg::Infer` came previously
Matthias Krüger [Sat, 15 Jan 2022 01:25:15 +0000 (02:25 +0100)]
Rollup merge of #92625 - inquisitivecrystal:mirbug-caller, r=michaelwoerister
Add `#[track_caller]` to `mirbug`
When a "'no errors encountered even though `delay_span_bug` issued" error results from the `mirbug` function, the file location information points to the `mirbug` function itself, rather than its caller. This doesn't make sense, since the caller is the real source of the bug. Adding `#[track_caller]` will produce diagnostics that are more useful to anyone fixing the ICE.
Matthias Krüger [Sat, 15 Jan 2022 01:25:14 +0000 (02:25 +0100)]
Rollup merge of #92382 - clarfonthey:const_convert, r=scottmcm
Extend const_convert to rest of blanket core::convert impls
This adds constness to all the blanket impls in `core::convert` under the existing `const_convert` feature, tracked by #88674.
Existing impls under that feature:
```rust
impl<T> const From<T> for T;
impl<T, U> const Into<U> for T where U: ~const From<T>;
impl<T> const ops::Try for Option<T>;
impl<T> const ops::FromResidual for Option<T>;
impl<T, E> const ops::Try for Result<T, E>;
impl<T, E, F> const ops::FromResidual<Result<convert::Infallible, E>> for Result<T, F> where F: ~const From<E>;
```
Additional impls:
```rust
impl<T: ?Sized, U: ?Sized> const AsRef<U> for &T where T: ~const AsRef<U>;
impl<T: ?Sized, U: ?Sized> const AsRef<U> for &mut T where T: ~const AsRef<U>;
impl<T: ?Sized, U: ?Sized> const AsMut<U> for &mut T where T: ~const AsMut<U>;
impl<T, U> const TryInto<U> for T where U: ~const TryFrom<T>;
impl<T, U> const TryFrom<U> for T where U: ~const Into<T>;
```
Matthias Krüger [Sat, 15 Jan 2022 01:25:14 +0000 (02:25 +0100)]
Rollup merge of #92191 - jackh726:issue-89352, r=nikomatsakis
Prefer projection candidates instead of param_env candidates for Sized predicates
Fixes #89352
Also includes some drive by logging and verbose printing changes that I found useful when debugging this, but I can remove this if needed.
This is a little hacky - but imo no more than the rest of `candidate_should_be_dropped_in_favor_of`. Importantly, in a Chalk-like world, both candidates should be completely compatible.
Noah Lev [Mon, 10 Jan 2022 20:24:20 +0000 (12:24 -0800)]
Make `AVG_PART_LENGTH` a power of 2
I seem to recall that in general, it's best to request an allocation
with a size that's a power of 2. The low estimate of 5 was probably a
little too low as well.
bors [Fri, 14 Jan 2022 17:31:28 +0000 (17:31 +0000)]
Auto merge of #92883 - matthiaskrgr:rollup-uoudywx, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #92045 (Don't fall back to crate-level opaque type definitions.)
- #92381 (Suggest `return`ing tail expressions in async functions)
- #92768 (Partially stabilize `maybe_uninit_extra`)
- #92810 (Deduplicate box deref and regular deref suggestions)
- #92818 (Update documentation for doc_cfg feature)
- #92840 (Fix some lints documentation)
- #92849 (Clippyup)
- #92854 (Use the updated Rust logo in rustdoc)
- #92864 (Fix a missing dot in the main item heading)
PS: This was introduce yesterday by https://github.com/rust-lang/rust/pull/92526 (the migration from Tera to Askama) and is not currently observable in the nightly doc.
It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).
Matthias Krüger [Fri, 14 Jan 2022 06:47:32 +0000 (07:47 +0100)]
Rollup merge of #92381 - ThePuzzlemaker:issue-92308, r=estebank
Suggest `return`ing tail expressions in async functions
This PR fixes #92308.
Previously, the suggestion to `return` tail expressions (introduced in #81769) did not apply to `async` functions, as the suggestion checked whether the types were equal disregarding `impl Future<Output = T>` syntax sugar for `async` functions. This PR changes that in order to fix a potential papercut.
I'm not sure if this is the "right" way to do this, so if there is a better way then please let me know.
I amended an existing test introduced in #81769 to add a regression test for this, if you think I should make a separate test I will.
bors [Fri, 14 Jan 2022 03:17:11 +0000 (03:17 +0000)]
Auto merge of #92844 - matthiaskrgr:rollup-z5wb6yi, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #90001 (Make rlib metadata strip works with MIPSr6 architecture)
- #91687 (rustdoc: do not emit tuple variant fields if none are documented)
- #91938 (Add `std::error::Report` type)
- #92006 (Welcome opaque types into the fold)
- #92142 ([code coverage] Fix missing dead code in modules that are never called)
- #92277 (rustc_metadata: Stop passing `CrateMetadataRef` by reference (step 1))
- #92334 (rustdoc: Preserve rendering of macro_rules matchers when possible)
- #92807 (Update cargo)
- #92832 (Update RELEASES for 1.58.)
Esteban Kuber [Mon, 10 Jan 2022 22:02:19 +0000 (22:02 +0000)]
Parse `Ty?` as `Option<Ty>` and provide structured suggestion
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.