promote debug_assert to assert when possible and useful
This PR fixed a very old issue https://github.com/rust-lang/rust/issues/94705 to clarify and improve the POSIX error checking, and some of the checks are skipped because can have no benefit, but I'm sure that this can open some interesting discussion.
Fixes https://github.com/rust-lang/rust/issues/94705
cc: `@tavianator`
cc: `@cuviper`
Update cargo
8 commits in ce40690a5e4e315d3dab0aae1eae69d0252c52ac..efd4ca3dc0b89929dc8c5f5c023d25978d76cb61
2022-08-09 22:32:17 +0000 to 2022-08-12 01:28:28 +0000
- Use `std:🧵:scope` to replace crossbeam (rust-lang/cargo#10977)
- [docs] Remove extra "in" from `cargo-test.md` (rust-lang/cargo#10978)
- Enable two windows tests (rust-lang/cargo#10930)
- Improve error msg for get target runner (rust-lang/cargo#10968)
- Ensure rustc-echo-wrapper works with an overridden build.target-dir (rust-lang/cargo#10962)
- Switch back to `available_parallelism` (rust-lang/cargo#10969)
- Only override published resolver when the workspace is different (rust-lang/cargo#10961)
- Add `CARGO_LOG` to "Environment variables Cargo reads" (rust-lang/cargo#10967)
This was incorrectly inserting the ExprField as a sibling of the struct
expression.
This required adjusting various parts which were looking at parent node
of a field expression to find the struct.
This helps simplify the code. It also fixes it to use the correct parent
when lowering. One consequence is the `non_snake_case` lint needed
to change the way it looked for parent nodes in a struct pattern.
This also includes a small fix to use the correct `Target` for
expression field attribute validation.
This extends the LintLevelBuilder to handle lint level attributes on
struct expression fields and pattern fields.
This also updates the early lints to honor lint levels on generic
parameters.
Attributes on struct expression fields were not being checked for
validity. This adds the fields as HIR nodes so that `CheckAttrVisitor`
can visit those nodes to check their attributes.
Attributes on pattern struct fields were not being checked for validity.
This adds the fields as HIR nodes so that the `CheckAttrVisitor` can
visit those nodes to check their attributes.
Update to LLVM 15
For preliminary testing. Some LLVM 15 compatibility fixes were applied separately in #99512.
Release timeline:
* LLVM 15 branched on Jul 26.
* The final LLVM 15.0.0 release is scheduled for Sep 6.
* Current nightly (1.65.0) is scheduled for Nov 3.
Changes in this PR (apart from the LLVM update):
* Pass `--set llvm.allow-old-toolchain` for many Docker images. LLVM 16 will require GCC >= 7.1, while LLVM 15 still allows older compilers with an option. Specify the option for builders still using GCC 5.4. #95026 updated some of the used toolchains, but not all.
* Use the `+atomics-32` target feature for thumbv6m.
* Explicitly link libatomic when cross-compiling LLVM to 32-bit target.
* Explicitly disable zstd support, to avoid libzstd.so dependency.
New LLVM patches ([commits](https://github.com/rust-lang/llvm-project/commits/rustc/15.0-2022-08-09)):
* [rust-only] Fix ICE with GCC 5.4 (15be58d7f0)
* [rust-only] Fix build with GCC 5.4 (774edc10fa)
* ~~[rust-only] Fix build with GCC 5.2 (1a6069a7bb)~~
* ~~[rust-only] Fix ICE with GCC 5.2 (493081f290)~~
* ~~[rust-only] Fix build with GCC 5.2 (0fc5979d73)~~
* [backported] Addition of `+atomics` target feature (57bdd9892d).
* [backported] Revert compiler-rt change that broke powerpc (9c68b43915)
* [awaiting backport] Fix RelLookupTableConverter on gnux32 (639388a05f / https://github.com/llvm/llvm-project/issues/57021)
Tested images: dist-x86_64-linux, armhf-gnu, arm-android, dist-s390x-linux, dist-x86_64-illumos, dist-x86_64-freebsd, wasm32, dist-x86_64-musl, dist-various-1, dist-riscv64-linux, dist-mips-linux, dist-mipsel-linux, dist-powerpc-linux, dist-aarch64-linux, dist-x86_64-apple, x86_64-msvc-1, x86_64-msvc-2, dist-various-2, dist-arm-linux
Tested up to the usual ipv6 error: test-various, i686-gnu, x86_64-gnu-nopt
r? `@ghost`
In our source page highlighting, we were generating `<span class="op">`
tags for all "operators", including e.g. `<` `>` around generic
parameters, `*`, `&`. This contributed significantly to DOM size, but
we don't actually style `.op` except in the ayu theme.
Remove the styles for `.op` in ayu, and stop generating the `<span>`s.
This reduces DOM size of an example page[1] from 265,938 HTML elements
to 242,165 elements, a 9% reduction.
[1]:
https://doc.rust-lang.org/nightly/src/core/up/up/stdarch/crates/core_arch/src/x86/avx512f.rs.html
Stringify non-shorthand visibility correctly
This makes `stringify!(pub(in crate))` evaluate to `pub(in crate)` rather than `pub(crate)`, matching the behavior before the `crate` shorthand was removed. Further, this changes `stringify!(pub(in super))` to evaluate to `pub(in super)` rather than the current `pub(super)`. If the latter is not desired (it is _technically_ breaking), it can be undone.
Fixes#99981
`@rustbot` label +C-bug +regression-from-stable-to-beta +T-compiler
Add `x.sh` and `x.ps1` shell scripts
This is a more ambitious version of https://github.com/rust-lang/rust/pull/98716.
It still changes the x.py shebang back to python3, for compatibility with non-Unix systems,
but also adds alternative entrypoints for systems without `python3` installed.
These scripts will be necessary for the rust entrypoint (#94829), so I see
little downside in adding them early.
I'll update the dev-guide to suggest using these instead of x.py once this is merged.
Fixes https://github.com/rust-lang/rust/issues/98650
r? `@Mark-Simulacrum` cc `@dtolnay` `@CAD97` `@yoshuawuyts`
make raw_eq precondition more restrictive
Specifically, don't allow comparing pointers that way. Comparing pointers is subtle because you have to talk about what happens to the provenance.
This matches what [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=9eb1dfb8a61b5a2d4a7cee43df2717af), and all existing users are fine with this.
If raw_eq on pointers is ever desired, we can adjust the intrinsic spec and Miri implementation as needed, but for now that seems just unnecessary. Also, this is a const intrinsic, and in const, comparing pointers this way is *not possible* -- so if we allow the intrinsic to compare pointers in general, we need to impose an extra restrictions saying that in const-context, pointers are *not* okay.
