Update dist-s390x-dist image
Update to Ubuntu 20.04 and crosstool-ng 1.24.0. I've upgraded the
ct-ng config and then manually reset the kernel and glibc versions
to the oldest supported.
Specifically, we're updating from kernel 2.6.32.68 to 2.6.32.71
and glibc 2.11.1 to 2.12.1 here. The compiler toolchain is also
updated, but I don't think that's relevant for compatibility.
I've also enabled LLD, so this fixes#94324.
r? `@Mark-Simulacrum` cc `@uweigand`
Update to Ubuntu 20.04 and crosstool-ng 1.24.0. I've updated the
ct-ng config and then manually reset the kernel and glibc versions
to the oldest supported.
Specifically, we're updating from kernel 2.6.32.68 to 2.6.32.71
and glibc 2.11.1 to 2.12.1 here. The compiler toolchain is also
updated, but I don't think that's relevant for compatibility.
Improve `--check-cfg` implementation
This pull-request is a mix of improvements regarding the `--check-cfg` implementation:
- Simpler internal representation (usage of `Option` instead of separate bool)
- Add --check-cfg to the unstable book (based on the RFC)
- Improved diagnostics:
* List possible values when the value is unexpected
* Suggest if possible a name or value that is similar
- Add more tests (well known names, mix of combinations, ...)
r? ```@petrochenkov```
Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped
As a part of stabilizing the scrape examples extension in Cargo, I uncovered a bug where examples cannot be scraped from tests. See this test: https://github.com/rust-lang/cargo/pull/10343/files#diff-27aa4f012ebfebaaee61498d91d2370de460628405d136b05e77efe61e044679R2496
The issue is that when rustdoc is run on a test file, because `--test` is not passed as a rustc option, then functions annotated with `#[test]` are ignored by the compiler. So this PR changes rustdoc so when `--test` is passed in conjunction with a `--scrape-example-<suffix>` flag, then the `test` field of `rustc_interface::Config` is true.
r? `@camelid`
Add MemTagSanitizer Support
Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html).
On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead.
On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR.
# Usage
`-Zsanitizer=memtag -C target-feature="+mte"`
# Comments/Caveats
* MemTagSanitizer is only supported on AArch64 targets with hardware support
* Requires `-C target-feature="+mte"`
* LLVM MemTagSanitizer currently only performs stack tagging.
# TODO
* Tests
* Example
Update tracking issue numbers for inline assembly sub-features
The main tracking issue for inline assembly is [closed](https://github.com/rust-lang/rust/issues/72016#issuecomment-1022332954), further tracking of the remaining sub-features has been moved to separate tracking issues.
Use `optflag` for `--report-time`
Essentially, what is described here:
https://github.com/rust-lang/rust/issues/64888#issuecomment-1008047228
There is one difference. The comment proposes to add a
`--report-time-color` option. This change instead uses libtest's
existing `--color` option for that purpose.
Update books
## nomicon
3 commits in 9493715a6280a1f74be759c7e1ef9999b5d13e6f..90993eeac93dbf9388992de92965f99cf6f29a03
2022-01-27 19:00:32 -0800 to 2022-02-13 12:44:12 +0900
- Fix a small typo in exception-safety.md (rust-lang/nomicon#341)
- Make `Vec::new` public in vec-alloc.md (rust-lang/nomicon#336)
- Fix a syntax error in leaking.md (rust-lang/nomicon#335)
## reference
6 commits in 411c2f0d5cebf48453ae2d136ad0c5e611d39aec..70fc73a6b908e08e66aa0306856c5211312f6c05
2022-01-30 12:46:37 -0800 to 2022-02-14 19:33:01 -0800
- Document pre-Rust-2021 special case for IntoIterator method lookup (rust-lang/reference#1154)
- Mention std::is_aarch64_feature_detected (rust-lang/reference#1061)
- Fix link to the Bastion of the Turbofish (rust-lang/reference#1161)
- Improve associated constant item CTFE timing section (rust-lang/reference#1147)
- document `#![feature(const_generics_defaults)]` (rust-lang/reference#1098)
- Update patterns allowed in @ patterns (rust-lang/reference#1158)
## book
6 commits in 98904efaa4fc968db8ff59cf2744d9f7ed158166..67b768c0b660a069a45f0e5d8ae2f679df1022ab
2022-01-29 21:22:31 -0500 to 2022-02-09 21:52:41 -0500
- Snapshot of ch18 for nostarch
- Remove mention of destructuring references as that's not covered currently
- Add note that exhaustiveness checking doesn't extend to match guards
- Change match guard example to actually be unexpressable with patterns alone
- Corrected listing number from 9-10 to 9-13
- Remove duplicate paragraph after No Starch related changes
## rustc-dev-guide
3 commits in 8763adb62c712df69b1d39ea3e692b6d696cc4d9..62f58394ba7b203f55ac35ddcc4c0b79578f5706
2022-01-26 14:01:40 -0800 to 2022-02-11 08:42:50 -0500
- Correction, building stage3 compiler (rust-lang/rustc-dev-guide#1298)
- Triage some date references (rust-lang/rustc-dev-guide#1293)
- mention test folders for cfg(bootstrap) (rust-lang/rustc-dev-guide#1294)
This change adds a flag for configuring control-flow protection in the
LLVM backend. In Clang, this flag is exposed as `-fcf-protection` with
options `none|branch|return|full`. This convention is followed for
`rustc`, though as a codegen option: `rustc -Z
cf-protection=<none|branch|return|full>`.
Co-authored-by: BlackHoleFox <blackholefoxdev@gmail.com>
Drop time dependency from bootstrap
This was only used for the inclusion of 'current' dates into our manpages, but
it is not clear that this is practically necessary. The manpage is essentially
never updated, and so we can likely afford to keep a manual date in these files.
It also seems possible to just omit it, but that may cause other tools trouble,
so avoid doing that for now.
This is largely done to reduce bootstrap complexity; the time crate is not particularly
small and in #92480 would have started pulling in num-threads, which does runtime
thread count detection. I would prefer to avoid that, so filing this to just drop the nearly
unused dependency entirely.
r? `@pietroalbini`
Add more *-unwind ABI variants
The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"
cc `@rust-lang/wg-ffi-unwind`
This was only used for the inclusion of 'current' dates into our manpages, but
it is not clear that this is practically necessary. The manpage is essentially
never updated, and so we can likely afford to keep a manual date in these files.
It also seems possible to just omit it, but that may cause other tools trouble,
so avoid doing that for now.
Add new target armv7-unknown-linux-uclibceabi (softfloat)
This adds the new target `armv7-unknown-linux-uclibceabi (softfloat)`. It is of course similar to `armv7-unknown-linux-uclibceabihf (hardfloat)` which was just recently added to rust except that it is `softfloat`.
My interest lies in the Broadcom BCM4707/4708/BCM4709 family, notably found in some Netgear and Asus consumer routers. The armv7 Cortex-A9 cpus found in these devices do not have an fpu or NEON support.
With this patch I've been able to bootstrap rustc, std and host tools `(extended = true)` to run on the target device for native compilation, allowing the target to be used as a development platform.
With the recent addition of `armv7-unknown-linux-uclibceabihf (hardfloat)` it looks like many of the edge cases of using the uclibc c-library are getting worked out nicely. I've been able to compile some complex projects. Some patching still needed in some crates, but getting there for sure. I think `armv7-unknown-linux-uclibceabi` is ready to be a tier 3 target.
I use a cross-toolchain from my project to bootstrap rust.
https://github.com/lancethepants/tomatoware
The goal of this project is to create a native development environment with support for various languages.
mips64-openwrt-linux-musl: Add Tier 3 target
Tier 3 tuple for Mips64 OpenWrt toolchain.
This add first-time support for OpenWrt. Future Tier3 targets will be added as I test them.
Signed-off-by: Donald Hoskins <grommish@gmail.com>
Stabilize `-Z instrument-coverage` as `-C instrument-coverage`
(Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121)
This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.)
Many, many people have tested this support, and there are numerous reports of it working as expected.
Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option.
Addressing questions raised in the tracking issue:
> If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)
This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration.
> The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?
This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version).
> The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.
Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement.
The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization.
The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.
Add links to the reference and rust by example for asm! docs and lints
These were previously removed in #91728 due to broken links.
cc ``@ehuss`` since this updates the rust-by-example submodule
Add x86_64-pc-windows-msvc linker-plugin-lto instructions
I had some trouble getting cross language LTO working for this target, in part because the very few links of documentation I could find were linux-centric and because of a few very specific errors I ran into. I'm not sure if this is the correct place to document this, but this is one of the first links I found when looking for documentation so it might be the best place for it.
add OpenBSD platform-support page
It mentions x86_64, i686, aarch64 and sparc64 which are actively maintained and used on OpenBSD (binaries provided by standard package distribution on OpenBSD).
I volontary kept `powerpc-unknown-openbsd` unmentioned as it was added by `@Yn0ga` in #82733, and I am unaware if it is functional or not (I doubt as I added libc support only few days ago, and std `c_char` signess was wrong). `@Yn0ga` maybe you comment on your `powerpc-unknown-openbsd` usage ?
Add preliminary support for inline assembly for msp430.
The `llvm_asm` macro was removed recently, and the MSP430 backend relies on inline assembly to build useful embedded apps. I conveniently "found" time to implement basic support for the new inline `asm` macro syntax with the help of `@Amanieu` :D.
In addition to tests in the compiler, I have tested this locally against deployed MSP430 code and have not found any noticeable differences in firmware operation or `objdump` disassemblies between the old `llvm_asm` and the new `asm` syntax.
