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.
Auto merge of #97925 - the8472:cgroupv1, r=joshtriplett
Add cgroupv1 support to available_parallelism
Fixes #97549
My dev machine uses cgroup v2 so I was only able to test that code path. So the v1 code path is written only based on documentation. I could use some help testing that it works on a machine with cgroups v1:
Rollup merge of #99617 - ehuss:update-mdbook, r=Dylan-DPC
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.
Auto merge of #93397 - joshtriplett:sort-floats, r=Amanieu
Add `[f32]::sort_floats` and `[f64]::sort_floats`
It's inconvenient to sort a slice or Vec of floats, compared to sorting integers. To simplify numeric code, add a convenience method to `[f32]` and `[f64]` to sort them using `sort_unstable_by` with `total_cmp`.
Rollup merge of #99602 - RalfJung:xsv, r=Mark-Simulacrum
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.
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. Fixes rust-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.
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)
Rollup merge of #99579 - CleanCut:expect-warning, r=joshtriplett
Add same warning to Result::expect as Result::unwrap
I was reading a recent blog post by Jimmy Hartzell and [he noted](https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/#context):
> I will however note that the documentation of `unwrap` comes with [a warning not to use it](https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap). The warning is framed in terms of the fact that `unwrap` may panic, but the [documentation of `expect`](https://doc.rust-lang.org/std/result/enum.Result.html#method.expect), where this is equally true, does not come with such a warning.
It _is_ equally true. Let's add the same warning to `expect`. This PR is a copy-and-paste of the warning text from the docstring for `unwrap`.
Rollup merge of #99539 - compiler-errors:bidirectional-block-suggestions, r=fee1-dead
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?
Rollup merge of #98868 - tmiasko:unreachable-coverage, r=wesleywiser
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.
Rollup merge of #98174 - Kixunil:rename_ptr_as_mut_const_to_cast, r=scottmcm
Rename `<*{mut,const} T>::as_{const,mut}` to `cast_`
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
Sorry, didn't notice ACP process exists, opened https://github.com/rust-lang/libs-team/issues/51
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`
Auto merge of #99501 - lcnr:check-regions-infcx, 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.
Auto merge of #99567 - matthiaskrgr:rollup-08hh3r4, r=matthiaskrgr
Rollup of 11 pull requests
Successful merges:
- #98707 (std: use futex-based locks on Fuchsia)
- #99413 (Add `PhantomData` marker for dropck to `BTreeMap`)
- #99454 (Add map_continue and continue_value combinators to ControlFlow)
- #99523 (Fix the stable version of `AsFd for Arc<T>` and `Box<T>`)
- #99526 (Normalize the arg spans to be within the call span)
- #99528 (couple of clippy::perf fixes)
- #99549 (Add regression test for #52304)
- #99552 (Rewrite `orphan_check_trait_ref` to use a `TypeVisitor`)
- #99557 (Edit `rustc_index::vec::IndexVec::pick3_mut` docs)
- #99558 (Fix `remap_constness`)
- #99559 (Remove unused field in ItemKind::KeywordItem)
Rollup merge of #98707 - joboet:fuchsia_locks, r=m-ou-se
std: use futex-based locks on Fuchsia
This switches `Condvar` and `RwLock` to the futex-based implementation currently used on Linux and some BSDs. Additionally, `Mutex` now has its own, priority-inheriting implementation based on the mutex in Fuchsia's `libsync`. It differs from the original in that it panics instead of aborting when reentrant locking is detected.
Rename `<*{mut,const} T>::as_{const,mut}` to `cast_`
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
Auto merge of #98162 - nextsilicon:support_lto_embed_bitcode, r=davidtwco
Allow to disable thinLTO buffer to support lto-embed-bitcode lld feature
Hello
This change is to fix issue (https://github.com/rust-lang/rust/issues/84395) in which passing "-lto-embed-bitcode=optimized" to lld when linking rust code via linker-plugin-lto doesn't produce the expected result.
Instead of emitting a single unified module into a llvmbc section of the linked elf, it emits multiple submodules.
This is caused because rustc emits the BC modules after running llvm `createWriteThinLTOBitcodePass` pass.
Which in turn triggers a thinLTO linkage and causes the said issue.
This patch allows via compiler flag (-Cemit-thin-lto=<bool>) to select between running `createWriteThinLTOBitcodePass` and `createBitcodeWriterPass`.
Note this pattern of selecting between those 2 passes is common inside of LLVM code.
The default is to match the old behavior.
Auto merge of #93718 - thomcc:used-macho, r=pnkfelix
Only compile #[used] as llvm.compiler.used for ELF targets
This returns `#[used]` to how it worked prior to the LLVM 13 update. The intention is not that this is a stable promise.
I'll add tests later today. The tests will test things that we don't actually promise, though.
It's a deliberately small patch, mostly comments. And assuming it's reviewed and lands in time, IMO it should at least be considered for uplifting to beta (so that it can be in 1.59), as the change broke many crates in the ecosystem, even if they are relying on behavior that is not guaranteed.
# Background
LLVM has two ways of preventing removal of an unused variable: `llvm.compiler.used`, which must be present in object files, but allows the linker to remove the value, and `llvm.used` which is supposed to apply to the linker as well, if possible.
Prior to LLVM 13, `llvm.used` and `llvm.compiler.used` were the same on ELF targets, although they were different elsewhere. Prior to our update to LLVM 13, we compiled `#[used]` using `llvm.used` unconditionally, even though we only ever promised behavior like `llvm.compiler.used`.
In LLVM 13, ELF targets gained some support for preventing linker removal of `llvm.used` via the SHF_RETAIN section flag. This has some compatibility issues though: Concretely: some older versions `ld.gold` (specifically ones prior to v2.36, released in Jan 2021) had a bug where it would fail to place a `#[used] #[link_section = ".init_array"]` static in between `__init_array_start`/`__init_array_end`, leading to code that does this failing to run a static constructor. This is technically not a thing we guarantee will work, is a common use case, and is needed in `libstd` (for example, to get access to `std::env::args()` even if Rust does not control `main`, such as when in a `cdylib` crate).
As a result, when updating to LLVM 13, we unconditionally switched to using `llvm.compiler.used`, which mirror the guarantees we make for `#[used]` and doesn't require the latest ld.gold. Unfortunately, this happened to break quite a bit of things in the ecosystem, as non-ELF targets had come to rely on `#[used]` being slightly stronger. In particular, there are cases where it will even break static constructors on these targets[^initinit] (and in fact, breaks way more use cases, as Mach-O uses special sections as an interface to the OS/linker/loader in many places).
As a result, we only switch to `llvm.compiler.used` on ELF[^elfish] targets. The rationale here is:
1. It is (hopefully) identical to the semantics we used prior to the LLVM13 update as prior to that update we unconditionally used `llvm.used`, but on ELF `llvm.used` was the same as `llvm.compiler.used`.
2. It seems to be how Clang compiles this, and given that they have similar (but stronger) compatibility promises, that makes sense.
[^initinit]: For Mach-O targets: It is not always guaranteed that `__DATA,__mod_init_func` is a GC root if it does not have the `S_MOD_INIT_FUNC_POINTERS` flag which we cannot add. In most cases, when ld64 transformed this section into `__DATA_CONST,__mod_init_func` it gets applied, but it's not clear that that is intentional (let alone guaranteed), and the logic is complex enough that it probably happens sometimes, and people in the wild report it occurring.
[^elfish]: Actually, there's not a great way to tell if it's ELF, so I've approximated it.
This is pretty ad-hoc and hacky! We probably should have a firmer set of guarantees here, but this change should relax the pressure on coming up with that considerably, returning it to previous levels.
---
Unsure who should review so leaving it open, but for sure CC `@nikic`
Auto merge of #99540 - Mark-Simulacrum:bump-beta, r=jyn514
Bump to latest beta bootstrap compiler
Hopefully this will address https://github.com/rust-lang/rust/issues/99538, but I'm not sure we can confirm that without rolling it out. Should be safe in general, so likely little risk to just landing this.
The Atelier [Thu, 21 Jul 2022 00:23:46 +0000 (17:23 -0700)]
Fix doctest imports using as_crate feature
Within core, `use self::` does not work to import these items.
And because core is not core_simd, neither does the existing `use`.
So, use this quirky hack instead, switching the import on a feature.
Auto merge of #99058 - michaelwoerister:remove-stable-set-and-map, r=nagisa
Remove the unused StableSet and StableMap types from rustc_data_structures.
The current implementation is not "stable" in the same sense that `HashStable` and `StableHasher` are stable, i.e. across compilation sessions. So, in my opinion, it's better to remove those types (which are basically unused anyway) than to give the wrong impression that these are safe for incr. comp.
I plan to provide new "stable" collection types soon that can be used to replace `FxHashMap` and `FxHashSet` in query results (see [draft](https://github.com/michaelwoerister/rust/commit/69d03ac7a7d651a397ab793e9d78f8fce3edf7a6)). It's unsound that `HashMap` and `HashSet` implement `HashStable` (see https://github.com/rust-lang/rust/issues/98890 for a recent P-critical bug caused by this) -- so we should make some progress there.
projects / rust.git / log