Plugin interface cleanup
The first commit performs two uncontroversial cleanups. The second commit removes `#[plugin_registrar]` and instead requires you to export a `__rustc_plugin_registrar` function, this will require a change to servo's script_plugins (cc `@jdm)`
`x.py setup` hardlinks this file into .git/hooks. Prior to this commit,
that led to the following warning emitted by `git commit`:
hint: The '.git/hooks/pre-commit' hook was ignored because it's not set as executable.
Making the checked-in script executable fixes this issue, as the
hardlinked copy uses the same flags.
It looks like the file was originally executable, but that bit was
unset in commit b908905b3d of
https://github.com/rust-lang/rust/pull/85305. It's possible that was
unintentional.
`never_loop`: suggest using an `if let` instead of a `for` loop
changelog: suggest using an `if let` statement instead of a `for` loop that [`never_loop`]s
Fixes#7537, r? `@camsteffen.`
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
From what I can tell, the goal of the tests is to ensure that the error
formatting is correct. I think this is still being tested as intended
after this change.
Various refactorings of the TAIT infrastructure
Before this PR we used to store the opaque type knowledge outside the `InferCtxt`, so it got recomputed on every opaque type instantiation.
I also removed a feature gate check that makes no sense in the planned lazy TAIT resolution scheme
Each commit passes all tests, so this PR is best reviewed commit by commit.
r? `@spastorino`
LLVM codegen: Don't emit zero-sized padding for fields
Currently padding is emitted before fields of a struct and at the end of the struct regardless of the ABI. Even if no padding is required zero-sized padding fields are emitted. This is not useful and - more importantly - it make it impossible to generate the exact vector types that LLVM expects for certain ARM SIMD intrinsics. This change should unblock the implementation of many ARM intrinsics using the `unadjusted` ABI, see https://github.com/rust-lang/stdarch/issues/1143#issuecomment-827404092.
This is a proof of concept only because the field lookup now takes O(number of fields) time compared to O(1) before since it recalculates the mapping at every lookup. I would like to find out how big the performance impact actually is before implementing caching or restricting this behavior to the `unadjusted` ABI.
cc `@SparrowLii` `@bjorn3`
([Discussion on internals](https://internals.rust-lang.org/t/feature-request-add-a-way-in-rustc-for-generating-struct-type-llvm-ir-without-paddings/15007))
typeck: don't suggest inaccessible fields in struct literals and suggest ignoring inaccessible fields in struct patterns
Fixes#87872.
This PR adjusts the missing field diagnostic logic in typeck so that when any of the missing fields in a struct literal or pattern is inaccessible then the error is less confusing, even if some of the missing fields are accessible.
See also #76524.
Clarify terms in rustdoc book
Fixes#70898
I chose to completely remove the term directive over attribute because rustdoc has a lint called `invalid_codeblock_attributes` and the term attributes is used throughout the book. I slightly changed the introductory sentence to describe the relationship between annotations and attributes.
I also moved the text explaining the example from below the blocks to above the blocks which is more in line with the rest of the book. I also changed the description for the `should_panic` attribute as I found it a little confusing. Finally, some of the blocks were `text` and some were `rust` so I changed them all to `text` which is in line with the rest of the book.
Fix heading colours in Ayu theme
Closes#87828
The issue seems to stem from #87210 where code headings were changed from a heading containing a `code` element to a heading with the `code-header` class. `rustdoc.css` was updated, but `ayu.css` was missed.
correctly handle enum variants in `opt_const_param_of`
Fixes#87542
`opt_const_param_of` was returning `None` for args on an enum variant `Enum::Variant::<10>` because we called `generics_of` on the enum variant which has no generics.
r? `@oli-obk`
removed references to parent/child from std::thread documentation
- also clarifies how thread.join and detaching of threads works
- the previous prose implied that there is a relationship between a
spawning thread and the thread being spawned, and that "child" threads
couldn't outlive their "parents" unless detached, which is incorrect.
Added the `Option::unzip()` method
* Adds the `Option::unzip()` method to turn an `Option<(T, U)>` into `(Option<T>, Option<U>)` under the `unzip_option` feature
* Adds tests for both `Option::unzip()` and `Option::zip()`, I noticed that `.zip()` didn't have any
* Adds `#[inline]` to a few of `Option`'s methods that were missing it
Constify implementations of `(Try)From` for int types
I believe this to be one of the (many?) things blocking const (Range) iterators.
~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done
