Add by-value arrays to `improper_ctypes` lint
Hi,
C doesn't have a notion of passing arrays by value, only by reference/pointer.
Rust currently will pass it correctly by reference by it looks very misleading, and can confuse the borrow checker to think a move had occurred.
Fixes#58905 and fixes#24578.
We could also improve the borrow checker here but I think it's kinda a waste of work if we instead just tell the user it's an invalid FFI call.
(My first PR to `rustc` so if I missed some test or formatting guideline please tell me :) )
Use `eq_opaque_type_and_type` when type-checking closure signatures
This handles the case where a user explicitly annotations a closure
signature with a opaque return type.
Fixes#63263
Stabilize nested self receivers in 1.41.0
Previously, only `Self`, `&Self`, `&mut Self`, `Arc<Self>`, `Rc<Self>`,
and `Box<Self>` were available as stable method receivers.
This commit stabilizes nested uses of all the above types.
However, nested receivers remain non-object-safe.
* `Place` is no longer recursive.
* The `cmt` type alias is removed
* `Upvar` places no longer include the dereferences of the environment
closure or of by reference captures.
* All non-dereference projections are combined to a single variant.
* Various unnecessary types and methods have been removed.
rustc: move debug info from LocalDecl and UpvarDecl into a dedicated VarDebugInfo.
This PR introduces a MIR "user variable" debuginfo system, which amounts to mapping a variable name, in some `SourceScope`, to a `Place`, so that:
* each name can appear multiple times (e.g. due to macro hygiene), even in the same scope
* each `Place` can appear multiple times (e.g. in the future from optimizations like NRVO, which collapse multiple MIR locals into one)
* the `Place`s aren't limited to just locals, so they can describe the (right now quite ad-hoc) closure upvars and generator saved state fields, and can be properly transformed by optimizations (e.g. inlining - see `src/test/mir-opt/inline-closure-captures.rs`)
The main motivation for this was that #48300 and further optimizations were blocked on being able to describe complex debuginfo transformations (see https://github.com/rust-lang/rust/pull/48300#discussion_r170020762).
<hr/>
In the textual representation, the "user variable" debuginfo can be found in each scope, and consists of `debug NAME => PLACE;` "declarations", e.g. the MIR for `let x = ...; let y = ...; ...` is now:
```rust
let _1: T; // in scope 0 at ...
scope 1 {
debug x => _1; // in scope 1 at ...
let _2: T; // in scope 1 at ...
scope 2 {
debug y => _2; // in scope 2 at ...
}
}
```
For reference, this is how the information was represented before this PR:
(notably, the scopes in which the variables are visible for debuginfo weren't even shown anywhere, making `scope 2` look pointless, and user variable names were part of MIR locals)
```rust
let _1: T; // "x" in scope 0 at ...
scope 1 {
let _2: T; // "y" in scope 1 at ...
scope 2 {
}
}
```
cc @nikomatsakis @michaelwoerister
Format libcore with rustfmt
I am interested in whether we can begin cautious incremental progress on #66688 and assess along the way whether we can keep the disruption sufficiently small.
This PR applies rustfmt with default settings to files in src/libcore *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in `outstanding_files`, the relevant commands were:
```console
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
```
Repeating this process several months apart should get us coverage of most of the rest of libcore.
When a const function is being evaluated, as long as all its
arguments are zero-sized-types (or it has no arguments) then we
can trivially memoize the evaluation result using the existing
query mechanism.
This commit applies rustfmt with default settings to files in
src/libcore *that are not involved in any currently open PR* to minimize
merge conflicts. The list of files involved in open PRs was determined
by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in `outstanding_files`, the
relevant commands were:
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libcore.
