Upgrade Emscripten targets to use upstream LLVM backend
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
r? @alexcrichton
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
Return `false` from `needs_drop` for all zero-sized arrays.
Resolves#65348.
This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving #65348 and #64945, but obviously it has much broader implications.
save-analysis: Don't ICE when resolving qualified type paths in struct members
Previously, we failed since we use `qpath_res` via typeck tables - when using those we need to pass in a HirId that's local to the definition path the tables are rooted at (otherwise we risk frame of reference mismatch and an assertion against invalid lookup).
In this case we can't get typeck tables for struct definition because it has no body, however the struct member type node is rooted under the struct definition and so we can't really do anything about it in terms of traversal.
Instead, we try to "nest" the tables as always but change the default behaviour to use empty typeck tables rather than silently trying to use the current ones. This does work as we expect and for prior art, we use the same approach in the [privacy](7bc94cc3c2/src/librustc_privacy/lib.rs (L332-L341)) [pass](7bc94cc3c2/src/librustc_privacy/lib.rs (L1007-L1028)).
Fixes#64659.
Fixes#64821.
r? @nikomatsakis (since this changes the default behaviour introduced in d7d3f197f6)
don't assume we can *always* find a return type hint in async fn
In particular, we sometimes cannot if there is an earlier error.
Fixes#65159
r? @cramertj, who reviewed the original PR
Remove last uses of gensyms
Underscore bindings now use unique `SyntaxContext`s to avoid collisions. This was the last use of gensyms in the compiler, so this PR also removes them.
closes#49300
cc #60869
r? @petrochenkov
add test to for the fix
add descriptive text for the fix
simplified code logics
update descriptive comments
update to cope with the tidyness requirement
merged commit suggestions
Co-Authored-By: varkor <github@varkor.com>
truncated redundant comments
update to cope with tidy-check
Remove an outdated test output file
It was accidentally introduced during some rebase, but it's no longer necessary and `--bless` removes it, but it doesn't fail testing.
syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`
Fixes https://github.com/rust-lang/rust/issues/65400.
The recovery comes in two flavors:
1. We know that `p2` is a binding so we can invert as `p2 @ p1`:
```rust
error: pattern on wrong side of `@`
--> $DIR/intersection-patterns.rs:13:9
|
LL | Some(x) @ y => {}
| -------^^^-
| | |
| | binding on the right, should be to the left
| pattern on the left, should be to the right
| help: switch the order: `y @ Some(x)`
```
2. Otherwise we emit a generic diagnostic for the lack of support for intersection patterns:
```rust
error: left-hand side of `@` must be a binding
--> $DIR/intersection-patterns.rs:23:9
|
LL | Some(x) @ Some(y) => {}
| -------^^^-------
| | |
| | also a pattern
| interpreted as a pattern, not a binding
|
= note: bindings are `x`, `mut x`, `ref x`, and `ref mut x`
```
For more on and-patterns, see e.g. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching#and-pattern.
r? @davidtwco
cc @varkor @lzutao
Don't discard value names when using address or memory sanitizer
The value names are used when reporting issues found by address
sanitizer or memory sanitizer. Avoid discarding names when those
sanitizers are enabled, unless explicitly requested to do otherwise.
