Test codegen of atomic compare-exchange with additional memory orderings
* Add a test for atomic operations introduced in #97423 & #98383.
* Add a test for fallback code generation strategy used on LLVM 12 introduced in #98385. Use a separate test case instead of a revision system since test will be gone once LLVM 12 is no longer supported.
Upgrade indexmap and thorin-dwp to use hashbrown 0.12
This removes the last dependencies on hashbrown 0.11.
This also upgrades to hashbrown 0.12.3 to fix a double-free (#99372).
Add fine-grained LLVM CFI support to the Rust compiler
This PR improves the LLVM Control Flow Integrity (CFI) support in the Rust compiler by providing forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types.
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue https://github.com/rust-lang/rust/issues/89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Thank you again, `@eddyb,` `@nagisa,` `@pcc,` and `@tmiasko` for all the help!
Rollup of 6 pull requests
Successful merges:
- #99298 (Make `ui-fulldeps/gated-plugins` and `ui-fulldeps/multiple-plugins` tests stage 2 only)
- #99396 (Add some additional double-adjustment regression tests)
- #99449 (Do not resolve associated const when there is no provided value)
- #99595 (Mark atomics as unsupported on thumbv6m)
- #99627 (Lock stdout once when listing tests)
- #99638 (Remove Clean trait implementation for hir::Ty and middle::Ty)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove Clean trait implementation for hir::Ty and middle::Ty
While going through the code, I realized that the "remove the Clean trait" effort which was started a while ago was never finished.
The idea behind it was to make it much simpler to go through the different clean steps (which is definitely not easy when you just have `something.clean(cx)`).
I'm planning to finish this effort.
cc ``@camelid``
r? ``@notriddle``
Do not resolve associated const when there is no provided value
Fixes#98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.
----
The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.
This root issue becomes problematic (as in #98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.
I'm not exactly sure _why_ this bug arises due to #96591 -- perhaps valtrees are evaluated more eagerly than in the old system?
r? ``@oli-obk`` or ``@lcnr`` since y'all are familiar with const eval and reviewed #96591, though feel free to reassign.
This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?
Add support for LLVM ShadowCallStack.
LLVMs ShadowCallStack provides backward edge control flow integrity protection by using a separate shadow stack to store and retrieve a function's return address.
LLVM currently only supports this for AArch64 targets. The x18 register is used to hold the pointer to the shadow stack, and therefore this only works on ABIs which reserve x18. Further details are available in the [LLVM ShadowCallStack](https://clang.llvm.org/docs/ShadowCallStack.html) docs.
# Usage
`-Zsanitizer=shadow-call-stack`
# Comments/Caveats
* Currently only enabled for the aarch64-linux-android target
* Requires the platform to define a runtime to initialize the shadow stack, see the [LLVM docs](https://clang.llvm.org/docs/ShadowCallStack.html) for more detail.
This commit improves the LLVM Control Flow Integrity (CFI) support in
the Rust compiler by providing forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their return and parameter types.
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
Update mdbook
This updates mdbook from 0.4.20 to 0.4.21
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0421
This contains a single fix that prevents mdbook from compiling on nightly (due to #99413). This will be necessary to keep everything working after the next master bootstrap switch.
cargotest: do not run quickcheck tests in xsv
Fixes https://github.com/rust-lang/rust/issues/73514
I know https://github.com/rust-lang/rust/issues/70659 discusses a larger overhaul of cargotest, but that seems to have stalled and I'd like to fix the immediate issue of PRs failing due to random test failures in xsv.
This still runs the vast majority of tests by numbers:
```
test result: ok. 394 passed; 0 failed; 0 ignored; 0 measured; 32 filtered out; finished in 1.84s
```
So the loss in test coverage is hopefully not too big.
Update books
## nomicon
1 commits in 70db9e4189f64d1d8e2451b1046111fb356b6dc2..8d1e4dccf71114ff56f328f671f2026d8e6b62a2
2022-06-27 20:47:21 +0900 to 2022-07-18 18:12:35 -0400
- Should be `align_of` instead of `size_of`
## reference
11 commits in 9fce337a55ee4a4629205f6094656195cecad231..a92be0fef439b3d8e0468d82cb24812d303520a0
2022-06-22 13:59:28 -0700 to 2022-07-21 19:01:23 -0700
- Add `IntoFuture::into_future` desugaring (rust-lang/reference#1233)
- Remove uses of the phrase "in Rust" (rust-lang/reference#1241)
- Revert "Add stable references of `macro_metavar_expr`" (rust-lang/reference#1242)
- tweaks
- further tweak addr_of exposition
- edits
- Apply suggestions from code review
- document raw-addr-of operators
- update union field type rules (rust-lang/reference#1238)
- clarify that references size_of_val can never exceed isize::MAX (rust-lang/reference#1186)
- Describe what `windows_subsystem` does (rust-lang/reference#1232)
## book
9 commits in cf2653a5ca553cbbb4a17f1a7db1947820f6a775..36383b4da21dbd0a0781473bc8ad7ef0ed1b6751
2022-07-05 12:07:58 -0400 to 2022-07-19 21:03:20 -0400
- Update ch16-02-message-passing.md
- Update snapshots with edits made to src that need to be checked
- Remove inconsistent newline. Fixesrust-lang/book#3240.
- add missing `b` in chapter 15.6
- Grammar: corrected 'as much' to 'as such'
- grammar: add missing 'of'
- Fix incorrect link for listing 13-06
- Correct method name
- Remove unused theme directories.
## rust-by-example
2 commits in 83724ca387a2a1cd3e8d848f62820020760e358b..3155db49b0d57cd82c65456ac210b69ecec5ccb1
2022-07-05 10:38:07 -0300 to 2022-07-05 20:35:53 -0300
- fix-type (rust-lang/rust-by-example#1565)
- add-examples-to-destructure-tuples (rust-lang/rust-by-example#1566)
## rustc-dev-guide
27 commits in eb83839e903a0a8f1406f7e941886273f189b26b..d5201cddace979b299ec1bf9fd8997338151aa9d
2022-07-03 15:17:39 +0900 to 2022-07-21 04:48:49 +0200
- Debuginfo tests now also support revisions.
- Link to rendered book directly
- Fix link to clippy sync docs
- remove stray markup
- renamed
- sync with hackmd version
- replace misleading name (rust-lang/rustc-dev-guide#1401)
- Remove a mention to Steve on r? example
- obey line length limit (part 3)
- obey line length limit (part 2)
- obey line length limit
- sync with hackmd
- add draft chapter
- add mdbook-mermaid
- use relative links
- fix some typos (rust-lang/rustc-dev-guide#1398)
- typo: monomorph docs
- Rename debugging_opts to unstable_opts, use link
- address review comment
- update date reference on MIR inliner
- remove outdated info on debugging
- small fixes to ty chapter (rust-lang/rustc-dev-guide#1390)
- Update the build instructions for the standard library
- overview.md: Link to existing Macro Expansion and Name Resolution docs (rust-lang/rustc-dev-guide#1388)
- Git-ignore `pulls.json` (rust-lang/rustc-dev-guide#1386)
- Revert "Add the config needed to get rust-analyzer working on src/bootstrap (rust-lang/rustc-dev-guide#1381)"
- Use `x.py check` instead of `cargo check` for build scripts (rust-lang/rustc-dev-guide#1384)
Fix hack that remaps env constness.
WARNING: might have perf implications.
Are there any more problems with having a constness in the `ParamEnv` now? :)
r? `@oli-obk`
Improve suggestions for returning binding
Fixes#99525
Also reworks the cause codes for match and if a bit, I think cleaning them up in a positive way.
We no longer need to call `could_remove_semicolon` in successful code, which might save a few cycles?
Fix unreachable coverage generation for inlined functions
To generate a function coverage we need at least one coverage counter,
so a coverage from unreachable blocks is retained only when some live
counters remain.
The previous implementation incorrectly retained unreachable coverage,
because it didn't account for the fact that those live counters can
belong to another function due to inlining.
Fixes#98833.
make vtable pointers entirely opaque
This implements the scheme discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/338: vtable pointers should be considered entirely opaque and not even readable by Rust code, similar to function pointers.
- We have a new kind of `GlobalAlloc` that symbolically refers to a vtable.
- Miri uses that kind of allocation when generating a vtable.
- The codegen backends, upon encountering such an allocation, call `vtable_allocation` to obtain an actually dataful allocation for this vtable.
- We need new intrinsics to obtain the size and align from a vtable (for some `ptr::metadata` APIs), since direct accesses are UB now.
I had to touch quite a bit of code that I am not very familiar with, so some of this might not make much sense...
r? `@oli-obk`
move `considering_regions` to the infcx
it seems weird to prove some obligations which constrain inference vars while ignoring regions in a context which considers regions. This is especially weird because even for a fulfillment context with ignored regions, we still added region outlives bounds when directly relating regions.
tbh our handling of regions is still very weird, but at least this is a step in the right direction imo.
r? rust-lang/types
Remove unused field in ItemKind::KeywordItem
For the keyword name, we use `Item::name` directly everywhere so there is no point into keeping it.
r? ``@notriddle``
