or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in https://github.com/rust-lang/rust/pull/63693 and https://github.com/rust-lang/rust/pull/61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc https://github.com/rust-lang/rust/issues/54883
cc @dlrobertson @matthewjasper
r? @petrochenkov
Improve searching in rustdoc and add tests
👋 I have made searching in rustdoc more intuitive, added a couple more tests and made a little shell script to aid testing. Closes#63005.
It took me quite a while to figure out how to run the tests for rustdoc (instead of running tests for other crates with rustdoc); the only pointer I found was [hidden in the rustc book](https://rust-lang.github.io/rustc-guide/rustdoc.html#cheat-sheet). Maybe this could be better documented? I shall be delighted to help if it is desirable.
When encountering a likely intended turbofish without `::`, bubble
up the diagnostic instead of emitting it to allow the parser to recover
more gracefully and avoid uneccessary type errors that are likely to be
wrong.
This moves the two methods from the `EmitterWriter` impl to trait
default methods in the `Emitter` trait so that they can be re-used by
the `AnnotateSnippetEmitterWriter`.
Closes#61810
The wasm32-wasi target respects configuration around `crt-static` in
general, but is defaulted to being static. This interacted badly with
code which validated the `cdylib` crate type for `wasm32-wasi`,
erroneously saying that the `cdylib` crate type wasn't supported on
`wasm32-wasi` by default. This commit sets the appropriate flag in
`wasm32_wasi`'s target specification to indicate that the `cdylib` crate
type is supported regardless of `crt-static`
Closes#64187
This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.
This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.
This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.
With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
Not doing this leads to building two copies of e.g. num_cpus in the
sysroot and _llvm deps, leading to conflicts between the two when
compiling librustc_codegen_llvm. It's not entirely clear why this is the
case after the changes in this PR but likely has something to do with a
subtle difference in ordering or similar.
Rollup of 11 pull requests
Successful merges:
- #62848 (Use unicode-xid crate instead of libcore)
- #63774 (Fix `window.hashchange is not a function`)
- #63930 (Account for doc comments coming from proc macros without spans)
- #64003 (place: Passing `align` = `layout.align.abi`, when also passing `layout`)
- #64030 (Fix unlock ordering in SGX synchronization primitives)
- #64041 (use TokenStream rather than &[TokenTree] for built-in macros)
- #64051 (Add x86_64-linux-kernel target)
- #64063 (Fix const_err with `-(-0.0)`)
- #64083 (Point at appropriate arm on type error on if/else/match with one non-! arm)
- #64100 (Fix const eval bug breaking run-pass tests in Miri)
- #64157 (Opaque type locations in error message for clarity.)
Failed merges:
r? @ghost
Fix const eval bug breaking run-pass tests in Miri
PR #63580 broke miri's ability to run the run-pass test suite with MIR
optimizations enabled. The issue was that we weren't properly handling
the substs and DefId associated with a Promoted value. This didn't break
anything in rustc because in rustc this code runs before the Inliner
pass which is where the DefId and substs can diverge from their initial
values. It broke Miri though because it ran this code again after
running the optimization pass.
r? @oli-obk
cc @RalfJung
Add x86_64-linux-kernel target
This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.
I wasn't totally sure about what the best name for this was.
There's one open question on whether we should use the LLVM generic x86_64-elf target, or the same one used for the Linux userspace.
r? @joshtriplett
Fix unlock ordering in SGX synchronization primitives
Avoid holding spinlocks during usercalls. This should avoid deadlocks in certain pathological scheduling cases.
cc @mzohreva @parthsane
r? @alexcrichton
place: Passing `align` = `layout.align.abi`, when also passing `layout`
Of the calls changed:
7/12 use `align` = `layout.align.abi`.
`from_const_alloc` uses `alloc.align`, but that is `assert_eq!` to `layout.align.abi`.
only 4/11 use something interesting for `align`.
Use unicode-xid crate instead of libcore
This PR proposes to remove `char::is_xid_start` and `char::is_xid_continue` functions from `libcore` and use `unicode_xid` crate from crates.io (note that this crate is already present in rust-lang/rust's Cargo.lock).
Reasons to do this:
* removing rustc-binary-specific stuff from libcore
* making sure that, across the ecosystem, there's a single definition of what rust identifier is (`unicode-xid` has almost 10 million downs, as a `proc_macro2` dependency)
* making it easier to share `rustc_lexer` crate with rust-analyzer: no need to `#[cfg]` if we are building as a part of the compiler
Reasons not to do this:
* increased maintenance burden: we'll need to upgrade unicode version both in libcore and in unicode-xid. However, this shouldn't be a too heavy burden: just running `./unicode.py` after new unicode version. I (@matklad) am ready to be a t-compiler side maintainer of unicode-xid. Moreover, given that xid-unicode is an important dependency of syn, *someone* needs to maintain it anyway.
* xid-unicode implementation is significantly slower. It uses a more compact table with binary search, instead of a trie. However, this shouldn't matter in practice, because we have fast-path for ascii anyway, and code size savings is a plus. Moreover, in #59706 not using libcore turned out to be *faster*, presumably beacause checking for whitespace with match is even faster.
<details>
<summary>old description</summary>
Followup to #59706
r? @eddyb
Note that this doesn't actually remove tables from libcore, to avoid conflict with https://github.com/rust-lang/rust/pull/62641.
cc https://github.com/unicode-rs/unicode-xid/pull/11
</details>
Extend Polonius fact generation for (some) move tracking
This PR will extend rustc to emit facts used for tracking moves and initialization in Polonius. It is most likely the final part of my master's thesis work.
