more clippy fixes
* remove unused unit values (clippy::unused_unit)
* make some let-if-bindings more idiomatic (clippy::useless_let_if_seq)
* clarify when we pass () to functions (clippy::unit_arg)
* don't redundantly repeat field names (clippy::redundant_field_names)
* remove redundant returns (clippy::needless_return)
* use let instead of match for matches with single bindings (clippy::match_single_binding)
* don't convert results to options just for matching (clippy::if_let_some_result)
parser: recover on `for<'a> |...| body` closures
When encountering `for` and `<` is 1 token ahead, interpret this as an explicitly quantified generic closure and recover, rather than attempting to parse a `for` loop. This provides both improved diagnostics as well as an insurance policy for the ability to use this as the syntax for generic closures in the future.
As requested by r? @eddyb
Amend Rc/Arc::from_raw() docs regarding unsafety
[This](https://stackoverflow.com/questions/59671647/is-it-safe-to-clone-a-type-erased-arc-via-raw-pointer) question on SO boils down to "is it safe to `::from_raw()` a `Rc<T>`/`Arc<T>` using a dummy `T` even if `T` is never dereferenced via the new `Rc`/`Arc`?". It almost never is.
This PR amends the docs of `from_raw()` regarding this point.
Test gdb pretty printing more and fix overzealous type substitution
Adresses a problem concerning printing BTreeMap / BTreeSet data in gdb: when the key or value type name contains substring "LeafNode", and the map has multiple nodes (e.g. more than 11 elements), printing causes an exception. E.g.
```
rustc -g - <<EOF
use std::collections::BTreeMap;
struct MyLeafNode(i8);
fn main() {
let m: BTreeMap<i8, MyLeafNode> = (0..12).map(|i| (i, MyLeafNode(i))).collect();
assert!(!m.is_empty());
}
EOF
```
```
$ rust-gdb rust_out
(gdb) b 7
(gdb) r
(gdb) p m
$1 = BTreeMap<i8, rust_out::MyLeafNode>(len: 12)Python Exception <class 'gdb.error'> No type named alloc::collections::btree::node::InternalNode<i8, rust_out::MyInternalNode>.:
use std::collections::BTreeMap;
```
The code was written in #56144 by @tromey (and later touched upon by @RalfJung in #57045, but I think that had nothing to do with the issues in this PR).
ast: Compress `AttrId` from `usize` to `u32`
An easy size win for `ast::Attribute` (96 bytes -> 88 bytes).
Also stop encoding/decoding `AttrId` entirely.
For issue 53957: revise unit test to focus on underlying bug of 23076.
Fix#53957 by revising unit test to focus on underlying bug of #23076.
Namely, this version focuses on the end-to-end behavior that the attempt to create the UDP binding will fail, regardless of the semantics of how particular DNS servers handle junk inputs.
(I spent some time trying to create a second more-focused test that would sidestep the DNS resolution, but this is not possible without more invasive changes to the internal infrastructure of `ToSocketAddrs` and what not. It is not worth it.)
symbol_names: treat ReifyShim like VtableShim.
Without this, the `#[track_caller]` tests don't pass with `-Zsymbol-mangling-version=v0`, because there is a symbol name collision between the `ReifyShim` and the original definition.
cc @anp
rustc: use LocalDefId instead of DefId in TypeckTables.
The logic in `TypeckTables`' implementation of `HashStable`, which created `DefId`s by combining a `CrateNum` from a `DefId` and a `DefIndex` from a `LocalDefId`, bothered me a bit.
I don't know how much this matters, but it works so might as well submit it.
Fix abort-on-eprintln during process shutdown
This commit fixes an issue where if `eprintln!` is used in a TLS
destructor it can accidentally cause the process to abort. TLS
destructors are executed after `main` returns on the main thread, and at
this point we've also deinitialized global `Lazy` values like those
which store the `Stderr` and `Stdout` internals. This means that despite
handling TLS not being accessible in `eprintln!`, we will fail due to
not being able to call `stderr()`. This means that we'll double-panic
quickly because panicking also attempt to write to stderr.
The fix here is to reimplement the global stderr handle to avoid the
need for destruction. This avoids the need for `Lazy` as well as the
hidden panic inside of the `stderr` function.
Overall this should improve the robustness of printing errors and/or
panics in weird situations, since the `stderr` accessor should be
infallible in more situations.
Avoid query type in generics
There are at the moment roughly 170 queries in librustc.
The way ty::query is structured, a lot of code is duplicated for each query.
I suspect this to be responsible for a part of librustc'c compile time.
This PR reduces the amount of code generic on the query,
replacing it by code generic on the key-value types.
This is split out of #69808,
and should not contain the perf regression.
cc #65031
add #[rustc_layout(debug)]
@eddyb recently told me about the `#[rustc_layout]` attribute, and I think it would be very useful if it could be used to print all the layout information Rust has about a type. When working with layouts (e.g. in Miri), it is often not clear how certain surface language features get represented internally. I have some awful hacks locally to be able to dump this debug information; with this attribute I could get it on the playground which is so much better. :)
do not 'return' in 'throw_' macros
In https://github.com/rust-lang/rust/pull/69839 we turned a closure into a `try` block, but it turns out that does not work with our `throw_` macros, which `return` so they skip the `try`.
Here we fix that. For some reason that means we also have to remove some `;`.
r? @oli-obk
hir: replace "items" terminology with "nodes" where appropriate.
The newly added `HirOwnerItems` confused me before I realized that "items" there actually referred to HIR nodes, not `hir:Item` or "item-like" (which we should IMO replace with "owner").
I suspect the naming had something to do with `ItemLocalId`'s use of "item".
That is, `ItemLocalId` could be interpreted to mean one of two things:
* `IntraItemNodeId` i.e. `IntraOwnerNodeId`
* this is IMO correct, and I'd even like to rename it, but I didn't want to throw that into this PR
* `IntraOwnerItemId`
* this is what `HirOwnerItems` would seem to imply
r? @Zoxc cc @michaelwoerister @nikomatsakis
rustc_infer: remove InferCtxt::closure_sig as the FnSig is always shallowly known.
That is, `ClosureSubsts` is always created (in `rustc_typeck::check::closure`) with a `FnSig`, as the number of inputs is known, even if they might all have inference types.
The only useful thing `InferCtxt::closure_sig` was doing is resolving an inference variable used just to get the `ty::FnPtr` containing that `FnSig` into `ClosureSubsts`.
The ideal way to solve this would be to add a constructor for `ClosureSubsts`, that combines the parent `Substs`, the closure kind, the signature, and capture types together, but for now I've went with resolving the inference types just after unifying them with the real types.
r? @nikomatsakis
Refactorings to get rid of rustc_codegen_utils
r? @eddyb
cc #45276
After this, the only modules left in `rustc_codegen_utils` are
- `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc?
- ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate)
I don't mind doing either of the above as part of this PR or a followup if you want.
