This shouldn't affect projects indirectly depending on wasm-bindgen
because cargo passes `--cap-lints=allow` when building dependencies.

It should be 0.3.74~ish.

This should help with backtraces on Android, QNX NTO 7.0, and Windows.

Previously `libname.a` naming was supported as a fallback when producing rlibs, but not when producing executables or dynamic libraries

This commit fixes an assert in the WASI-specific implementation of
thread sleep to ensure that sleeping for a very large period of time
blocks instead of panicking. This can come up when testing programs that
sleep "forever", for example.

Several compiler functions have `Option<!>` for their return type.
That's odd. The only valid return value is `None`, so why is this type
used?

Because it lets you write certain patterns slightly more concisely. E.g.
if you have these common patterns:
```
    let Some(a) = f() else { return };
    let Ok(b) = g() else { return };
```
you can shorten them to these:
```
    let a = f()?;
    let b = g().ok()?;
```
Huh.

An `Option` return type typically designates success/failure. How should
I interpret the type signature of a function that always returns (i.e.
doesn't panic), does useful work (modifying `&mut` arguments), and yet
only ever fails? This idiom subverts the type system for a cute
syntactic trick.

Furthermore, returning `Option<!>` from a function F makes things
syntactically more convenient within F, but makes things worse at F's
callsites. The callsites can themselves use `?` with F but should not,
because they will get an unconditional early return, which is almost
certainly not desirable. Instead the return value should be ignored.
(Note that some of callsites of `process_operand`, `process_immedate`,
`process_assign` actually do use `?`, though the early return doesn't
matter in these cases because nothing of significance comes after those
calls. Ugh.)

When I first saw this pattern I had no idea how to interpret it, and it
took me several minutes of close reading to understand everything I've
written above. I even started a Zulip thread about it to make sure I
understood it properly. "Save a few characters by introducing types so
weird that compiler devs have to discuss it on Zulip" feels like a bad
trade-off to me. This commit replaces all the `Option<!>` return values
and uses `else`/`return` (or something similar) to replace the relevant
`?` uses. The result is slightly more verbose but much easier to
understand.

…-patterns, r=nnethercote

Don't make statement nonterminals match pattern nonterminals

Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to `may_be_ident`:
https://github.com/rust-lang/rust/blob/ef71f1047e04438181d7cb925a833e2ada6ab390/compiler/rustc_parse/src/parser/nonterminal.rs#L21-L37

This has the unfortunate side effect that a `stmt` nonterminal eagerly matches against a `pat` nonterminal, leading to a parse error:
```rust
macro_rules! m {
    ($pat:pat) => {};
    ($stmt:stmt) => {};
}

macro_rules! m2 {
    ($stmt:stmt) => {
        m! { $stmt }
    };
}

m2! { let x = 1 }
```

This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal.

As a side-effect, I modified `Token::can_begin_pattern` to work correctly and used that in `Parser::nonterminal_may_begin_with`.

…z,notriddle

Separate core search logic with search ui

Currenty, the `search.js` mixed with UI/DOM manipulation codes and search logic codes, I propose to extract the search logic to a class for following benefits:

- Clean code. Separation of DOM manipulation and search logic can lead better code maintainability and easy code testings.
- Easy share the search logic for third party to utilize the search function, such as [Rust Search Extension](https://rust.extension.sh), https://query.rs.

This PR added a new class called `DocSearch`, which mainly expose following methods:

```js
class DocSearch {
	// Dependency inject searchIndex, rootPath and searchState
	constructor(rawSearchIndex, rootPath, searchState) {
		// build search index...
	}

	static parseQuery(userQuery) {
	}

	async execQuery(parsedQuery, filterCrates, currentCrate) {
	}
}
```

…=fmease

rustdoc-json: Add test for `Self` type

Inspired by rust-lang#128471, the rustdoc-json suite had no tests in place for the `Self` type. This PR adds one.

I've also manually checked locally that this test passes on 29e9248, confirming that adding `clean::Type::SelfTy` didn't change the JSON output. (potentially adding a self type to json (insead of (ab)using generic) is tracked in rust-lang#128522)

Updates rust-lang#81359

r? ````````@fmease````````

linker: Synchronize native library search in rustc and linker

Also search for static libraries with alternative naming (`libname.a`) on MSVC when producing executables or dynamic libraries, and not just rlibs.

This unblocks rust-lang#123436.

try-job: x86_64-msvc

Don't use `TyKind` in a lint

Allows us to remove an inherent method from `TyKind` from the type ir crate.

…fcw-to-deny, r=daxpedda,alexcrichton

Deny `wasm_c_abi` lint to nudge the last 25%

This shouldn't affect projects indirectly depending on wasm-bindgen because cargo passes `--cap-lints=allow` when building dependencies.

The motivation is that the ecosystem has mostly taken up the versions of wasm-bindgen that are compatible in general, but ~25% or so of recent downloads remain on lower versions. However, this change might still be unnecessarily disruptive. I mostly propose it as a discussion point.

…, r=tgross35

Re-enable android tests/benches in alloc/core

This is basically a revert of rust-lang#73729. These tests better work on android now; it's been 4 years and we don't use dlmalloc on that target anymore.

And I've validated that they should pass now with a try-build :)

…b22, r=workingjubilee

Bump backtrace to 0.3.74~ish

Commit: rust-lang/backtrace-rs@230570f

This should help with backtraces on Android, QNX NTO 7.0, and Windows.
It addresses a case of backtrace incurring undefined behavior on Android.

…d, r=workingjubilee

allow BufReader::peek to be called on unsized types

rust-lang#128405

…r=lcnr

Simplify some extern providers

Simplifies some extern crate providers:
1. Generalize the `ProcessQueryValue` identity impl to work on non-`Option` types.
2. Allow `ProcessQueryValue` to wrap its output in an `EarlyBinder`, to simplify `explicit_item_bounds`/`explicit_item_super_predicates`.
3. Use `{ table }` and friends more when possible.

…-dead

Remove `Option<!>` return types.

Several compiler functions have `Option<!>` for their return type. That's odd. The only valid return value is `None`, so why is this type used?

Because it lets you write certain patterns slightly more concisely. E.g. if you have these common patterns:
```
    let Some(a) = f() else { return };
    let Ok(b) = g() else { return };
```
you can shorten them to these:
```
    let a = f()?;
    let b = g().ok()?;
```
Huh.

An `Option` return type typically designates success/failure. How should I interpret the type signature of a function that always returns (i.e. doesn't panic), does useful work (modifying `&mut` arguments), and yet only ever fails? This idiom subverts the type system for a cute syntactic trick.

Furthermore, returning `Option<!>` from a function F makes things syntactically more convenient within F, but makes things worse at F's callsites. The callsites can themselves use `?` with F but should not, because they will get an unconditional early return, which is almost certainly not desirable. Instead the return value should be ignored. (Note that some of callsites of `process_operand`, `process_immedate`, `process_assign` actually do use `?`, though the early return doesn't matter in these cases because nothing of significance comes after those calls. Ugh.)

When I first saw this pattern I had no idea how to interpret it, and it took me several minutes of close reading to understand everything I've written above. I even started a Zulip thread about it to make sure I understood it properly. "Save a few characters by introducing types so weird that compiler devs have to discuss it on Zulip" feels like a bad trade-off to me. This commit replaces all the `Option<!>` return values and uses `else`/`return` (or something similar) to replace the relevant `?` uses. The result is slightly more verbose but much easier to understand.

r? ``````@cjgillot``````

…mease

Stop using `ty::GenericPredicates` for non-predicates_of queries

`GenericPredicates` is a struct of several parts: A list of of an item's own predicates, and a parent def id (and some effects related stuff, but ignore that since it's kinda irrelevant). When instantiating these generic predicates, it calls `predicates_of` on the parent and instantiates its predicates, and appends the item's own instantiated predicates too:

https://github.com/rust-lang/rust/blob/acb4e8b6251f1d8da36f08e7a70fa23fc581839e/compiler/rustc_middle/src/ty/generics.rs#L407-L413

Notice how this should result in a recursive set of calls to `predicates_of`... However, `GenericPredicates` is *also* misused by a bunch of *other* queries as a convenient way of passing around a list of predicates. For these queries, we don't ever set the parent def id of the `GenericPredicates`, but if we did, then this would be very easy to mistakenly call `predicates_of` instead of some other intended parent query.

Given that footgun, and the fact that we don't ever even *use* the parent def id in the `GenericPredicates` returned from queries like `explicit_super_predicates_of`, It really has no benefit over just returning `&'tcx [(Clause<'tcx>, Span)]`.

This PR additionally opts to wrap the results of `EarlyBinder`, as we've tended to use that in the return type of these kinds of queries to properly convey that the user has params to deal with, and it also gives a convenient way of iterating over a slice of things after instantiating.

…ozkan

Allow running `./x.py test compiler`

…er, r=compiler-errors

interpret/visitor: make memory order iteration slightly more efficient

Finally I know enough about RPIT to write this iterator signature correctly. :D

This means memory-order iteration now needs an allocation, but it avoids quadratic complexity (where it has to do a linear scan n times to find the n-th field in memory order), so that seems like a win overall. The changed code only affects Miri; the rustc changes are NOPs.

…r=workingjubilee

wasi: Fix sleeping for `Duration::MAX`

This commit fixes an assert in the WASI-specific implementation of thread sleep to ensure that sleeping for a very large period of time blocks instead of panicking. This can come up when testing programs that sleep "forever", for example.

I'll note that I haven't included a test for this since it's sort of difficult to test. I've tested this locally though that long sleeps do indeed block and short sleeps still only sleep for a short amount of time.