bors [Tue, 18 Jan 2022 02:32:36 +0000 (02:32 +0000)]
Auto merge of #93001 - flip1995:clippyup, r=Manishearth
Out of cycle Clippy update
I want to do an out-of-cycle sync for rust-lang/rust-clippy#8295, and possibly backport this to stable together with https://github.com/rust-lang/rust/issues/92938. If this doesn't get backported to stable, then I at least want to backport it to beta.
bors [Mon, 17 Jan 2022 23:01:35 +0000 (23:01 +0000)]
Auto merge of #93009 - matthiaskrgr:rollup-3fkxg6i, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #90498 (Clarifications in the target tier policy)
- #92164 (Implement `#[rustc_must_implement_one_of]` attribute)
- #92729 (rustc_codegen_llvm: Remove (almost) unused span parameter from many functions in metadata.rs)
- #92752 (Correct minor typos in some long error code explanations)
- #92801 (Enable wrapping words by default)
- #92825 (Rename environment variable for overriding rustc version)
- #92877 (Remove LLVMRustMarkAllFunctionsNounwind)
- #92936 (rustdoc: Remove `collect` in `html::markdown::parse`)
- #92956 (Add `log2` and `log10` to `NonZeroU*`)
- #92960 (Use `carrying_{mul|add}` in `num::bignum`)
Matthias Krüger [Mon, 17 Jan 2022 19:07:07 +0000 (20:07 +0100)]
Rollup merge of #92877 - Amanieu:remove_llvm_nounwind, r=Mark-Simulacrum
Remove LLVMRustMarkAllFunctionsNounwind
This was originally introduced in #10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.
In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.
Matthias Krüger [Mon, 17 Jan 2022 19:07:05 +0000 (20:07 +0100)]
Rollup merge of #92801 - jsha:overflow-wrap, r=GuillaumeGomez
Enable wrapping words by default
Faced with a very long word, browsers will let it overflow its
box horizontally rather than break it in the middle. We essentially
never want that behavior. We would rather break the word and keep it
inside its horizontal limits. So we apply a default overflow-wrap:
break-word/anywhere to the document as a while.
In some contexts we would rather add a horizontal scrollbar (code
blocks), or elide the excess text with an ellipsis (sidebar). Those
still work as expected.
Fixes #92771
[Some related discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/wrap.20.2F.20overflow.20.2F.20scroll) and a related issue: #92421.
Matthias Krüger [Mon, 17 Jan 2022 19:07:03 +0000 (20:07 +0100)]
Rollup merge of #92729 - michaelwoerister:remove-unused-span-debuginfo, r=petrochenkov
rustc_codegen_llvm: Remove (almost) unused span parameter from many functions in metadata.rs
Many functions and intermediate data structures in `rustc_codegen_llvm/src/debuginfo/metadata.rs` take a span parameter that is only used for providing a span to a `span_bug!()` invocation, in case the debuginfo typemap gets corrupted. However, this span does not really convey useful information as it just points to the first point a type is used -- and half of the time is initialized to `DUMMY_SP`.
This PR removes this span parameter from the module.
It also removes the following unused parameters from `composite_type_metadata()` together with an outdated comment:
```rust
// Ignore source location information as long as it
// can't be reconstructed for non-local crates.
_file_metadata: &'ll DIFile,
_definition_span: Span,
```
This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the "minimal complete definition" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma, though `#[rustc_must_implement_one_of]` is weaker atm.
Such attribute was long wanted. It can be, for example, used in `Read` trait to make transitions to recently added `read_buf` easier:
```rust
#[rustc_must_implement_one_of(read, read_buf)]
pub trait Read {
fn read(&mut self, buf: &mut [u8]) -> Result<usize> {
let mut buf = ReadBuf::new(buf);
self.read_buf(&mut buf)?;
Ok(buf.filled_len())
}
impl Read for Ty0 {}
//^ This will fail to compile even though all `Read` methods have default implementations
// Both of these will compile just fine
impl Read for Ty1 {
fn read(&mut self, buf: &mut [u8]) -> Result<usize> { /* ... */ }
}
impl Read for Ty2 {
fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ }
}
```
For now, this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it:
- Allow arbitrary requirements like `a | (b & c)`
- Allow multiple requirements like
- ```rust
#[rustc_must_implement_one_of(a, b)]
#[rustc_must_implement_one_of(c, d)]
```
- Make it appear in rustdoc documentation
- Change the syntax?
- Etc
Eventually, we should make an RFC and make this (or rather similar) attribute public.
---
I'm fairly new to compiler development and not at all sure if the implementation makes sense, but at least it passes tests :)
Matthias Krüger [Mon, 17 Jan 2022 19:07:01 +0000 (20:07 +0100)]
Rollup merge of #90498 - joshtriplett:target-tier-policy-draft-updates, r=Mark-Simulacrum
Clarifications in the target tier policy
We've added several targets since the introduction of the target tier policy. Based on experiences of those adding such targets, and discussions around such additions, clarify the target tier policy to make it easier to follow and work with.
None of these changes substantively change the requirements on targets. (In some cases the changes do direct target submitters to follow specific process requirements for the addition of a target, such as how to respond to requirements, where to put target-specific documentation, or what should appear in that documentation. Those changes are procedural in nature and document the procedures we already direct people to follow.)
- Clarify how to quote and respond to the target tier policy requirements. Several times, people have seemed unclear on how to respond to some of the policy requirements, particularly those that just state things the target developers must *not* do (e.g. not posting to PRs that break the target). Add a note that such requirements just need acknowledgement, nothing more.
- Clarify dependency requirements in the face of cross-compilation. I previously phrased this confusingly in terms of "host tools", since that is the case where an exception applies (allowing proprietary target libraries commonly used by binaries for the target). Rephrase it to apply equally to cross-compilation. This doesn't change the net effect of the requirements, since other requirements already cover the dependencies of the Rust toolchain.
- Clarify documentation about running binaries. The requirement for target documentation talks about "running tests", but tier 3 targets often don't support running the full testsuite, and in practice the documentation for how to run an individual binary may be more useful. Change "running tests" to "running binaries, or running tests".
- Explain where to place target-specific documentation (a subdirectory of platform-support, with a link from the platform-support entry for the target).
- Add a template for target-specific documentation.
bors [Mon, 17 Jan 2022 14:50:50 +0000 (14:50 +0000)]
Auto merge of #90986 - camsteffen:nested-filter, r=cjgillot
Replace `NestedVisitorMap` with generic `NestedFilter`
This is an attempt to make the `intravisit::Visitor` API simpler and "more const" with regard to nested visiting.
With this change, `intravisit::Visitor` does not visit nested things by default, unless you specify `type NestedFilter = nested_filter::OnlyBodies` (or `All`). `nested_visit_map` returns `Self::Map` instead of `NestedVisitorMap<Self::Map>`. It panics by default (unreachable if `type NestedFilter` is omitted).
One somewhat trixty thing here is that `nested_filter::{OnlyBodies, All}` live in `rustc_middle` so that they may have `type Map = map::Map` and so that `impl Visitor`s never need to specify `type Map` - it has a default of `Self::NestedFilter::Map`.
bors [Mon, 17 Jan 2022 09:40:29 +0000 (09:40 +0000)]
Auto merge of #92816 - tmiasko:rm-llvm-asm, r=Amanieu
Remove deprecated LLVM-style inline assembly
The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.
Matthias Krüger [Mon, 17 Jan 2022 05:08:19 +0000 (06:08 +0100)]
Rollup merge of #92981 - RalfJung:const_ptr_offset_from, r=dtolnay
fix const_ptr_offset_from tracking issue
The old tracking issue #41079 was for exposing those functions at all, and got closed when they were stabilized. We had nothing tracking their `const`ness so I opened a new tracking issue: https://github.com/rust-lang/rust/issues/92980.
Matthias Krüger [Mon, 17 Jan 2022 05:08:18 +0000 (06:08 +0100)]
Rollup merge of #92977 - kornelski:popdoc, r=dtolnay
Docs: recommend VecDeque instead of Vec::remove(0)
Suggestion based on a [discussion](https://internals.rust-lang.org/t/should-vec-have-a-try-remove-mut-self-usize-option-t-function/15964/9?u=kornel) where user needlessly struggled with `remove(0)` and accidentally created a quadratic cost.
Matthias Krüger [Mon, 17 Jan 2022 05:08:17 +0000 (06:08 +0100)]
Rollup merge of #92953 - azdavis:azdavis-copy-example, r=dtolnay
Copy an example to PartialOrd as well
In https://github.com/rust-lang/rust/pull/88202 I added an example for deriving PartialOrd on enums, but only later did I realize that I actually put the example on Ord.
This copies the example to PartialOrd as well, which is where I intended for it to be.
We could also delete the example on Ord, but I see there's already some highly similar examples shared between Ord and PartialOrd, so I figured we could leave it.
I also changed some type annotations in an example from `x : T` to the more common style (in Rust) of `x: T`.
Matthias Krüger [Mon, 17 Jan 2022 05:08:13 +0000 (06:08 +0100)]
Rollup merge of #92808 - compiler-errors:wrap-struct-shorthand-field-in-variant, r=davidtwco
Fix `try wrapping expression in variant` suggestion with struct field shorthand
Fixes a broken suggestion: [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=83fe2dbfe1485f8cfca1aef2a6582e77)
before:
```
error[E0308]: mismatched types
--> src/main.rs:7:19
|
7 | let x = Foo { bar };
| ^^^ expected enum `Option`, found integer
|
= note: expected enum `Option<i32>`
found type `{integer}`
help: try wrapping the expression in `Some`
|
7 | let x = Foo { Some(bar) };
| +++++ +
```
after:
```
error[E0308]: mismatched types
--> src/main.rs:7:19
|
7 | let x = Foo { bar };
| ^^^ expected enum `Option`, found integer
|
= note: expected enum `Option<i32>`
found type `{integer}`
help: try wrapping the expression in `Some`
|
7 | let x = Foo { bar: Some(bar) };
| ~~~~~~~~~~~~~~
```
r? ``@m-ou-se``
since you touched the code last in #91080
bors [Mon, 17 Jan 2022 02:06:54 +0000 (02:06 +0000)]
Auto merge of #92473 - petrochenkov:ltrattr2, r=Aaron1011
expand: Pick `cfg`s and `cfg_attrs` one by one, like other attributes
This is a rebase of https://github.com/rust-lang/rust/pull/83354, but without any language-changing parts ~(except for https://github.com/rust-lang/rust/pull/84110)~, i.e. the attribute expansion order is the same.
This is a pre-requisite for any other changes making cfg attributes closer to regular macro attributes
- Possibly changing their expansion order (https://github.com/rust-lang/rust/issues/83331)
- Keeping macro backtraces for cfg attributes, or otherwise making them visible after expansion without keeping them in place literally (https://github.com/rust-lang/rust/pull/84110).
Two exceptions to the "one by one" behavior are:
- cfgs eagerly expanded by `derive` and `cfg_eval`, they are still expanded in a batch, that's by design.
- cfgs at the crate root, they are currently expanded not during the main expansion pass, but before that, during `#![feature]` collection. I'll try to disentangle that logic later in a separate PR.
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.
bors [Sun, 16 Jan 2022 12:33:08 +0000 (12:33 +0000)]
Auto merge of #8284 - xFrednet:0000-update-copyright-year-i-am-procrastinating, r=giraffate
Update copyright year for Clippy (2022 edition)
At this point, I'm just searching for small things to do instead of sleeping or working on my bachelor thesis. :sweat_smile: Taking one day off will be fine :upside_down_face:
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 22:17:37 +0000 (22:17 +0000)]
Auto merge of #8274 - andrewarchi:master, r=camsteffen
Update markdown-it version
Fixes improperly-escaped pipes in Markdown tables for the [documentation of bad_bit_mask](https://rust-lang.github.io/rust-clippy/master/index.html#bad_bit_mask) and [ineffective_bit_mask](https://rust-lang.github.io/rust-clippy/master/index.html#ineffective_bit_mask). A column pipe takes precedence over inline code markers, so some back ticks are displayed literally and the pipes need to be escaped. I found no other occurrences of the same problem when searching rust-clippy by ```\|.*`.*\|```.
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.