Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.
Rollup of 5 pull requests
Successful merges:
- #60489 (Remove hamburger button from source code page)
- #60535 (Correct handling of arguments in async fn)
- #60579 (Rename `ParamTy::idx` to `ParamTy::index`)
- #60583 (Fix parsing issue with negative literals as const generic arguments)
- #60609 (Be a bit more explicit asserting over the vec rather than the len)
Failed merges:
r? @ghost
This is similar to `NonNull::cast`.
Compared to the `as` operator (which has a wide range of meanings
depending on the input and output types), a call to this method:
* Can only go from a raw pointer to a raw pointer
* Cannot change the pointer’s `const`ness
… even when the pointed types are inferred based on context.
This commit extends the logic used to determine what the expected
signature of a closure is so that it can also determine the expected
signature of a generator. This improves a diagnostic where the fn
signature was blamed instead of the generator body. It doesn't fix
fix the diagnostic for `async fn`.
This commit adds a test for the current behaviour of signature deduction
of generators when there is a type mismatch between the return type of
the function body and the signature.
rustc: Always handle exported symbols on the wasm target
Currently when linking an artifact rustc will only conditionally call
the `Linker::export_symbols` function, but this causes issues on some
targets, like WebAssembly, where it means that executable outputs will
not have the same symbols exported that cdylib outputs have. This commit
sinks the conditional call to `export_symbols` inside the various
implementations of the function that still need it, and otherwise the
wasm linker is configured to always pass through symbol visibility
lists.
This reverts commit 77bd4dc65406ba3cedbc779e6f6280868231912e.
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
The Genesis of Generic Germination
*Long had its coming been foretold: a collaborative effort with @yodaldevoid, set in motion by @jplatte, to beget a new Kind: one of a very different Sort to those that come before it. Amidst promises of ineffable powers previously thought unobtainable, few dared believe that the prophecies were true. But as they gazed upon that which claimed to be the Beginning, a few gentle sparks of hope fluttered deep within. It was not Time yet. But it was a Sign. And maybe, for some, that was enough.*
There's a long way to go, but we're at the point where we would benefit from GitHub's reviewing capabilities.
r? @eddyb
introduce unescape module
A WIP PR to gauge early feedback
Currently, we deal with escape sequences twice: once when we [lex](112f7e9ac5/src/libsyntax/parse/lexer/mod.rs (L928-L1065)) a string, and a second time when we [unescape](112f7e9ac5/src/libsyntax/parse/mod.rs (L313-L366)) literals. Note that we also produce different sets of diagnostics in these two cases.
This PR aims to remove this duplication, by introducing a new `unescape` module as a single source of truth for character escaping rules.
I think this would be a useful cleanup by itself, but I also need this for https://github.com/rust-lang/rust/pull/59706.
In the current state, the PR has `unescape` module which fully (modulo bugs) deals with string and char literals. I am quite happy about the state of this module
What this PR doesn't have yet are:
* [x] handling of byte and byte string literals (should be simple to add)
* [x] good diagnostics
* [x] actual removal of code from lexer (giant `scan_char_or_byte` should go away completely)
* [x] performance check
* [x] general cleanup of the new code
Diagnostics will be the most labor-consuming bit here, but they are mostly a question of just correctly adjusting spans to sub-tokens. The current setup for diagnostics is that `unescape` produces a plain old `enum` with various problems, and they are rendered into `Handler` separately. This bit is not actually required (it is possible to just pass the `Handler` in), but I like the separation between diagnostics and logic this approach imposes, and such separation should again be useful for #59706
cc @eddyb , @petrochenkov
... on different platforms.
Official rustdoc of
[`usize::to_le_bytes`](https://doc.rust-lang.org/std/primitive.usize.html#method.to_le_bytes)
displays signature
```
pub fn to_ne_bytes(self) -> [u8; 8]
```
which might be misleading: this function returns 4 bytes on 32-bit
systems.
