Changes:
````
rustup to https://github.com/rust-lang/rust/pull/70043
map_clone: avoid suggesting `copied()` for &mut
fix redundant_pattern_matching lint
Add tests for #1654
Don't trigger while_let_on_iterator when the iterator is recreated every iteration
Update issue_2356.stderr reference file
Update while_let_on_iterator tests
Fix while_let_on_iterator suggestion and make it MachineApplicable
Add lifetime test case for `new_ret_no_self`
rustup https://github.com/rust-lang/rust/pull/71215/
Downgrade match_bool to pedantic
Run fetch before testing if master contains beta
The beta branch update should not require a force push
Add a note to the beta sections of release.md
Remove apt-get upgrade again
Always use the deploy script and templates of the master branch
README: fix lit count line
clippy_dev: make it fatal when the regex for updating lint count does not match
`predecessors_for` will be removed soon
Rustup "Remove `BodyAndCache`"
Only run (late) internal lints, when they are warn/deny/forbid
Only run cargo lints, when they are warn/deny/forbid
span_lint_and_note now takes an Option<Span> for the note_span instead of just a span
Make lint also capture blocks and closures, adjust language to mention other mutex types
don't test the code in the lint docs
Switch to matching against full paths instead of just the last element of the path
Lint for holding locks across await points
Also mention `--fix` for nightly users
fix crash on issue-69020-assoc-const-arith-overflow.rs
Address review comments
remark fixes
Update CHANGELOG.md for Rust 1.43 and 1.44
update stderr file
util/fetch_prs_between.sh: Add Markdown formatted Link
factor ifs into function, add differing mutex test
Update the changelog update documentation
Apply suggestions from PR review
update span_lint_and_help call to six args
test for mutex eq, add another test case
use if chain
cargo dev fmt
fix map import to rustc_middle
dev update_lints
fix internal clippy warnings
change visitor name to OppVisitor
use Visitor api to find Mutex::lock calls
add note about update-all-refs script, revert redundant pat to master
move closures to seperate fns, remove known problems
use span_lint_and_help, cargo dev fmt
creating suggestion
progress work on suggestion for auto fix
Implement unsafe_derive_deserialize lint
Update empty_enum.stderr
Formatting and naming
Formatting and naming
Cleanup: `node_id` -> `hir_id`
Fix issue #2907.
Don't trigger toplevel_ref_arg for `for` loops
Cleanup: future_not_send: use `return_ty` method
Remove badge FIXME from Cargo.toml
Change note_span argument for span_lint_and_note.
Add an Option<Span> argument to span_lint_and_help.
Fixes internal lint warning in code base.
Implement collapsible_span_lint_calls lint.
````
Fixes#71453
Fix stable(since) attribute for BTreeMap::remove_entry
Stabilized in #70712.
Maybe checking that the since attributes are added correctly should be automated through tidy? This is the third PR I'm opening that fixes a stable(since) attribute for something meant to be stabilized in 1.43 / 1.44 initially but then only stabilized in 1.45. (the other two are #71571, #71574)
Cleanup and document `-C relocation-model`
As the title says, this is mostly a refactoring and documentation.
One potentially observable change here is that `-C relocation-model=default` now takes the default from the Rust target, rather than from the underlying LLVM target. In other words, `-C relocation-model=default` is now equivalent to not specifying the relocation model on command line at all.
Apparently no one used that option because it has other bugs as well, e.g. PIC `default` wasn't treated as PIC in some places.
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
0eaf304644/src/proto/h1/io.rs (L582-L594)
The referenced `sanitizer-address/Makefile` no longer exists, so perhaps these options are no longer necessary as well.
Even if they are still necessary, they should use `-C relocation-model=static` instead.
If an extern C function is defined as
```
extern "C" {
fn malloc(size: u32) -> *mut std::ffi::c_void;
}
```
on a 64-bit machine(ie. pointer sizes don't match), throw an undefined
behaviour.
Replace thread_local with generator resume arguments in box_region.
Fixes#68922.
Continuation of #70622. Added a short doc, hope it makes sense.
r? @jonas-schievink
Don't hold the predecessor cache lock longer than necessary
#71044 returns a `LockGuard` with the predecessor cache to callers of `Body::predecessors`. As a result, the lock around the predecessor cache could be held for an arbitrarily long time. This PR uses reference counting for ownership of the predecessor cache, meaning the lock is only ever held within `PredecessorCache::compute`. Checking this API for potential sources of deadlock is much easier now, since we no longer have to consider its consumers, only its internals.
This required removing `predecessors_for`, since there is no equivalent to `LockGuard::map` for `Arc` and `Rc`. I believe this could be emulated with `owning_ref::{Arc,Rc}Ref`, but I don't think it's necessary. Also, we continue to return an opaque type from `Body::predecessors` with the lifetime of the `Body`, not `'static`.
This depends on #71044. Only the last two commits are new.
r? @nikomatsakis
[breaking change] Disallow statics initializing themselves
fixes#71078
Self-initialization is unsound because it breaks privacy assumptions that unsafe code can make. In
```rust
pub mod foo {
#[derive(Debug, Copy, Clone)]
pub struct Foo {
x: (),
}
}
pub static FOO: foo::Foo = FOO;
```
unsafe could could expect that ony functions inside the `foo` module were able to create a value of type `Foo`.
Add all remaining `DefKind`s.
r? @eddyb or @Centril
~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~
~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
Rollup of 7 pull requests
Successful merges:
- #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`)
- #69813 (Implement BitOr and BitOrAssign for the NonZero integer types)
- #70712 (stabilize BTreeMap::remove_entry)
- #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`)
- #71544 (Replace filter_map().next() calls with find_map())
- #71545 (Fix comment in docstring example for Error::kind)
- #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.)
Failed merges:
r? @ghost
Add missing Send and Sync impls for linked list Cursor and CursorMut.
Someone pointed out these to me, and i think it's indeed reasonable to add those impl.
r? @Amanieu
Implement BitOr and BitOrAssign for the NonZero integer types
This provides overloaded operators for `NonZero$Int | NonZero$Int`, `NonZero$Int | $Int`, and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int`, for symmetry.
It's a pretty small conceptual addition, but is good becasue but avoids a case where the operation is obviously sound, but you'd otherwise need unsafe to do it.
In crates trying to minimize `unsafe` usage, this is unfortunate and makes working with `NonZero` types often not worth it, even if the operations you're doing are clearly sound.
I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information.
I'm not entirely confident what version I should have put down, so I followed https://www.whatrustisit.com. Hopefully it's correct for this.
Apologies in advance if this has come up before, but I couldn't find it.
This was only used for linkage test cases, which is already covered by
the run-make-fulldeps/symbol-visibility test -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
