Enable Control Flow Guard in rustbuild
Now that Rust supports Control Flow Guard (#68180), add a config.toml option to build the standard library with CFG enabled.
r? @nagisa
Selectively disable sanitizer instrumentation
Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.
implement proper linkchecker hardening
r? @JohnTitor
This implements proper linkcheck filtering... we might need to fiddle with a bit to adjust what is or isn't filtered, but this seems to work reasonable locally.
Instrument C / C++ in MemorySanitizer example
Modify the example to instrument C / C++ in addition to Rust, since it
will be generally required (e.g., when using libbacktrace for symbolication).
Detect use-after-scope bugs with AddressSanitizer
Enable use-after-scope checks by default when using AddressSanitizer.
They allow to detect incorrect use of stack objects after their scope
have already ended. The detection is based on LLVM lifetime intrinsics.
To facilitate the use of this functionality, the lifetime intrinsics are
now emitted regardless of optimization level if enabled sanitizer makes
use of them.
Rename `Alloc` to `AllocRef`
The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.
This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors.
For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one.
Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.
The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
Blocked on https://github.com/rust-lang/miri/pull/1160
Stabilize `#[repr(transparent)]` on `enum`s in Rust 1.42.0
# Stabilization report
The following is the stabilization report for `#![feature(transparent_enums)]`.
Tracking issue: https://github.com/rust-lang/rust/issues/60405
[Version target](https://forge.rust-lang.org/#current-release-versions): 1.42 (2020-01-30 => beta, 2020-03-12 => stable).
## User guide
A `struct` with only a single non-ZST field (let's call it `foo`) can be marked as `#[repr(transparent)]`. Such a `struct` has the same layout and ABI as `foo`. Here, we also extend this ability to `enum`s with only one variant, subject to the same restrictions as for the equivalent `struct`. That is, you can now write:
```rust
#[repr(transparent)]
enum Foo { Bar(u8) }
```
which, in terms of layout and ABI, is equivalent to:
```rust
#[repr(transparent)]
struct Foo(u8);
```
## Motivation
This is not a major feature that will unlock new and important use-cases. The utility of `repr(transparent)` `enum`s is indeed limited. However, there is still some value in it:
1. It provides conceptual simplification of the language in terms of treating univariant `enum`s and `struct`s the same, as both are product types. Indeed, languages like Haskell only have `data` as the only way to construct user-defined ADTs in the language.
2. In rare occasions, it might be that the user started out with a univariant `enum` for whatever reason (e.g. they thought they might extend it later). Now they want to make this `enum` `transparent` without breaking users by turning it into a `struct`. By lifting the restriction here, now they can.
## Technical specification
The reference specifies [`repr(transparent)` on a `struct`](https://doc.rust-lang.org/nightly/reference/type-layout.html#the-transparent-representation) as:
> ### The transparent Representation
>
> The `transparent` representation can only be used on `struct`s that have:
> - a single field with non-zero size, and
> - any number of fields with size 0 and alignment 1 (e.g. `PhantomData<T>`).
>
> Structs with this representation have the same layout and ABI as the single non-zero sized field.
>
> This is different than the `C` representation because a struct with the `C` representation will always have the ABI of a `C` `struct` while, for example, a struct with the `transparent` representation with a primitive field will have the ABI of the primitive field.
>
> Because this representation delegates type layout to another type, it cannot be used with any other representation.
Here, we amend this to include univariant `enum`s as well with the same static restrictions and the same effects on dynamic semantics.
## Tests
All the relevant tests are adjusted in the PR diff but are recounted here:
- `src/test/ui/repr/repr-transparent.rs` checks that `repr(transparent)` on an `enum` must be univariant, rather than having zero or more than one variant. Restrictions on the fields inside the only variants, like for those on `struct`s, are also checked here.
- A number of codegen tests are provided as well:
- `src/test/codegen/repr-transparent.rs` (the canonical test)
- `src/test/codegen/repr-transparent-aggregates-1.rs`
- `src/test/codegen/repr-transparent-aggregates-2.rs`
- `src/test/codegen/repr-transparent-aggregates-3.rs`
- `src/test/ui/lint/lint-ctypes-enum.rs` tests the interactions with the `improper_ctypes` lint.
## History
- 2019-04-30, RFC https://github.com/rust-lang/rfcs/pull/2645
Author: @mjbshaw
Reviewers: The Language Team
This is the RFC that proposes allowing `#[repr(transparent)]` on `enum`s and `union`.
- 2019-06-11, PR https://github.com/rust-lang/rust/pull/60463
Author: @mjbshaw
Reviewers: @varkor and @rkruppe
The PR implements the RFC aforementioned in full.
- 2019, PR https://github.com/rust-lang/rust/pull/67323
Author: @Centril
Reviewers: @davidtwco
The PR reorganizes the static checks taking advantage of the fact that `struct`s and `union`s are internally represented as ADTs with a single variant.
- This PR stabilizes `transparent_enums`.
## Related / possible future work
The remaining work here is to figure out the semantics of `#[repr(transparent)]` on `union`s and stabilize those. This work continues to be tracked in https://github.com/rust-lang/rust/issues/60405.
Modify the example to instrument C / C++ in addition to Rust, since it
will be generally required (e.g., when using libbacktrace for symbolication).
Additionally use rustc specific flag to track the origins of unitialized
memory rather than LLVM one.
Conditional compilation for sanitizers
Configure sanitize option when compiling with a sanitizer to make
it possible to execute different code depending on whether given
sanitizer is enabled or not.
Configure sanitize option when compiling with a sanitizer to make
it possible to execute different code depending on whether given
sanitizer is enabled or not.
Stabilize rustdoc theme options
Closes#54730
This PR stabilizes the `--themes` (now `--theme`) and `--theme-checker` (now `--check-theme`) options, for allowing users to add custom themes to their documentation.
Rustdoc includes two themes by default: `light` and `dark`. Using the `--theme` option, you can give rustdoc a CSS file to include as an extra theme for that render. Themes are named after the CSS file used, so using `--theme /path/to/your/custom-theme.css` will add a theme called `custom-theme` to the documentation.
Even though the CLI flag to add a theme is getting stabilized, there's no guarantee that a theme file will always have the same effect on documentation generated with future versions of rustdoc. To aid in ensuring that a theme will work, the flag `--check-theme` is also available, which compares the CSS rules defined by a custom theme against the ones used in the `light` theme. If the `light` theme defines a CSS rule that the custom theme does not, rustdoc will report an error. (Rustdoc also performs this check for themes given to `--theme`, but only reports a warning when a difference is found.)
