Improve the ICE message for invalid nullary intrinsic calls
In https://github.com/rust-lang/rust/issues/148104, we found the panic message here rather confusing, and (if I'm reading the tea leaves right) that's because the intended audience for either side of the phrase is very different. I think this is more clear if/when this is encountered by users.
I expect this ICE to be hit in practice by people calling the `size_of` and `align_of` intrinsics, so it's now _kind of_ helpful for those users too.
The original effort to stop backends from needing to support nullary intrinsics added a note to all these const-only intrinsics, but when https://github.com/rust-lang/rust/pull/147793 ported two more the paragraph wasn't added. I've added it.
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
StateTransform: Only load pin field once.
The current implementation starts by transforming all instances of `_1` into `(*_1)`, and then traverses the body again to transform `(*_1)` into `(*(_1.0))`, and again for `Derefer`.
This PR changes the implementation to only traverse the body once. As `_1.0` cannot be not modified inside the body (we just changed its type!), we have no risk of loading from the wrong pointer.
compiletest: Simplify passing arguments to spawned test threads
The current code structure was heavily influenced by wanting to match the libtest executor as closely as possible.
Now that the libtest executor has been removed, we can get rid of some complexity that no longer serves a purpose in the new executor.
---
The renaming of `ShouldPanic` is only semi-related, but I included it here because it's small, and as a separate PR it would have conflicted with this one.
r? jieyouxu
chore: Update to the latest annotate-snippets
This PR updates `annotate-snippets` to the latest version and updates the adapter code[^1] so that `AnnotateSnippetEmitter`'s output matches `HumanEmitter`'s output. If anyone would like to see the differences[^2] between `AnnotateSnippetEmitter` and `HumanEmitter`, [I have a branch](https://github.com/Muscraft/rust/tree/annotate-snippets-default-renderer) where `AnnotateSnippetEmitter` is used in place of `HumanEmitter`.
[^1]: A lot of the adapter code changes are based on code for `HumanEmitter`.
[^2]: Some of the test differences will go away when rust-lang/rust#148001 and rust-lang/rust#148004 are merged.
Improvements to attribute suggestions
Changes in commit 1:
- Add `AcceptContext::suggestions`, which retrieves the suggestions for the currently parsing attribute
- This happens to fix a bug in the way `#[macro_export`]. Closes https://github.com/rust-lang/rust/pull/147987
Changes in commit 2:
- Add a check to the suggestions function so the suggestions for attributes in cfg_attr are nicer. Fixes https://github.com/rust-lang/rust/issues/147693
This is also part (but not all) of the changes needed to unblock https://github.com/rust-lang/rust/pull/147945
r? `@jdonszelmann`
Stop passing resolver disambiguator state to AST lowering.
AST->HIR lowering can use a disjoint set of `DefPathData` as the resolver, so we don't need to pass the disambiguator state.
r? `@oli-obk`
Example
---
```rust
fn f() {
if $0foo.bar() {}
}
```
**Before this PR**
"let" not in completion list
**After this PR**
```rust
fn f() {
if let $1 = $0foo.bar() {}
}
```
test(frontmatter): Rename tests to make coverage more obvious
When working on the stabilization report (rust-lang/rust#148051), I found it annoying to determine what cases were covered because areas of the frontmatter feature were either not in the file name or in inconsistent locations.
This moves the area of frontmatter to the start of the file name and the moves to more specific the later in the file name so coverage is easier to see.
Tracking issue: rust-lang/rust#136889
Fix compiling `CondVar::wait_timeout` on 32-bit Apple platforms
Fixes https://github.com/rust-lang/rust/issues/147776. I feel like there's a cleaner way to write this, but that probably requires further refactoring.
The build can be tested with `./x build --target arm64_32-apple-watchos` (or with any other 32-bit Apple target).
Tested it works at runtime on an Intel Macbook Pro with macOS 10.12.6, in x86 emulation mode with something similar to `./x test library/std --target x86_64-apple-darwin,i686-apple-darwin`, as well as with a custom test with a timeout of `Duration::from_secs((u32::MAX as u64) + 1)` (which the naive fix would have treated as a duration of 1 second).
r? libs
CC ``@joboet``
compiletest: Add concrete examples for some config/test path fields
Seeing a specific example path can be much more enlightening than trying to figure out what the prose is gesturing towards.
Also, in some cases the existing comments were incorrect or misleading, as demonstrated by the example paths.
The example paths were determined by dumping them directly out of the config with `dbg!`, and then lightly anonymizing them for example purposes.
---
No functional changes.
r? jieyouxu
Remove needs-asm-support directive in tests with explicit targets
The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary.
These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does.
Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support.
hir_analysis: add missing sizedness bounds
Depends on rust-lang/rust#144064
Default sizedness bounds were not being added to `explicit_super_predicates_of` and `explicit_implied_predicates_of` which meant that a trait bound added to a associated type projection would be missing the implied predicate of the default sizedness supertrait of that trait.
An unexpected consequence of this change was that the check for multiple principals was now finding an additional `MetaSized` principal when eagerly expanding trait aliases - which is fixed by skipping `MetaSized` when elaborating trait aliases in lowering `dyn TraitAlias`.
Spun out of https://www.github.com/rust-lang/rust/pull/142642
In the future, I want the rustdoc-json test suite to invoke rustdoc
twice, once with `--output-format=json`, and once with the (not yet
implemented) `--output-format=postcard` flag.
Doing that requires being able to explicitly tell the `.document()`
function which format to use, rather then implicitly using json in the
rustdoc-json suite, and HTML in all others.
