Enable ASan, TSan, UBSan for aarch64-apple-darwin.
I confirmed ASan, TSan, UBSan all work for me locally with `clang` on my new Macbook Air.
~This requires https://github.com/rust-lang/llvm-project/pull/86~
Use Array.prototype.filter instead of open-coding
Part of #79052, originally suggested in https://github.com/rust-lang/rust/pull/79052#discussion_r523468743 by `@jyn514`
Besides making main.js smaller (always a plus), this also performs better by using the optimized filter implementation in your browser's JavaScript engine (according to `@GuillaumeGomez,` an 84% performance improvement).
Fix tests that incorrectly used `!@has` instead of `@!has`
The command is ``@!has`,` not `!`@has`.` I don't think these checks were
doing anything before! Ideally we would accept `!`@has`` as well, or at
least fail tests that use `!`@has`.` The current behavior seems to be
silently ignoring the check, which is very confusing.
r? `@GuillaumeGomez`
In which we start to parse const generics defaults
As discussed in this [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/const.20generic.20defaults), this PR extracts the parsing parts from `@JulianKnodt's` PR #75384 for a better user-experience using the newly stabilized `min_const_generics` (albeit temporary) as shown in #80507: trying to use default values on const generics currently results in parse errors, as if the user didn't use the correct syntax (which is somewhat true but also misleading).
This PR extracts (and slightly modifies in a couple places) `@JulianKnodt's` parsing code (with attribution if I've done everything correctly), AST and HIR changes, and feature gate setup.
This feature is now marked as "incomplete" and thus will also print out the expected "const generics default values are unstable" error instead of a syntax error. Note that, as I've only extracted the parsing part, the actual feature will not work at all if enabled. There will be ICEs, and inference errors on the const generics default values themselves.
Fixes#80507.
Once this merges, I'll:
- modify the const generics tracking issue to refer to the `const_generics_defaults` gate rather than the older temporary name it uses there.
- create the GH `F-const_generics_defaults` label
r? `@varkor`
- Adds optional default values to const generic parameters in the AST
and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate
Add edition 2021.
🎆 Happy new ~~year~~ Rust. 🍾
This adds --edition=2021, and updates suggestions about 2018 to say "2018 *or later*".
Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922
---
Edit: This adds the new edition as *unstable*. Without `-Z unstable-options`, `--edition=2021` results in:
```
$ rustc --edition=2021
error: edition 2021 is unstable and only available with -Z unstable-options.
```
Update LLVM
- [GlobalISel][IRTranslator] Fix a crash when the use of an extractvalue is a non-dominated metadata use.
- [asan] Use dynamic shadow memory position on Apple Silicon macOS
r? ``@cuviper``
Fix broken ./x.py install
During my tarball refactorings in https://github.com/rust-lang/rust/pull/79788 I changed the directory layout used by the tarball generation code, and that broke the other parts of rustbuild which hardcoded the paths of those directories. Namely, `./x.py install` relied on the uncompressed copy of the tarball left behind by `fabricate`/`rust-installer`, causing https://github.com/rust-lang/rust/issues/80494.
While the easy fix for https://github.com/rust-lang/rust/issues/80494 would've been to just update the hardcoded paths to match the new structure, that fix would leave us in the same situation if we were to change the directory layout again in the future. Instead I refactored the code to return a `GeneratedTarball` struct as the output of all the dist steps, and I put all the paths the rest of rustbuild needs to care about in its fields. That way, future changes to `src/bootstrap/tarball.rs` will not break other stuff.
This PR is best reviewed commit-by-commit.
r? `@Mark-Simulacrum`
`@rustbot` modify labels: beta-nominated beta-accepted T-release
The command is `@!has`, not `!@has`. I don't think these checks were
doing anything before! Ideally we would accept `!@has` as well, or at
least fail tests that use `!@has`. The current behavior seems to be
silently ignoring the check, which is very confusing.
