| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove spotlight
I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes, the result is very clear: it's not useful. Considering the amount of code we have just to run it, I think it's definitely worth it to remove it.
r? @kinnison
cc @ollie27
|
|
Expose target libdir information via print command
With custom libdir it is required to have an access to library placement.
See https://github.com/RazrFalcon/cargo-bloat/issues/51
|
|
Update books
## nomicon
8 commits in 3e6e1001dc6e095dbd5c88005e80969f60e384e1..9f797e65e6bcc79419975b17aff8e21c9adc039f
2019-12-14 22:08:52 +0000 to 2020-03-04 03:45:13 +0100
- Rustup to latest rustc (rust-lang-nursery/nomicon#203)
- (minor) Add backticks around type names (rust-lang-nursery/nomicon#197)
- Add book.toml (rust-lang-nursery/nomicon#185)
- Rename `Alloc` to `AllocRef` (rust-lang-nursery/nomicon#188)
- Lifetimes: explain how to fix destructor example (rust-lang-nursery/nomicon#195)
- mention soundness (rust-lang-nursery/nomicon#194)
- Fix example in FFI section Calling Rust from C (rust-lang-nursery/nomicon#193)
- Removed repeated word (rust-lang-nursery/nomicon#191)
## reference
8 commits in 64239df6d173562b9deb4f012e4c3e6e960c4754..559e09caa9661043744cf7af7bd88432d966f743
2020-02-10 19:05:13 +0100 to 2020-03-02 01:17:14 +0100
- Syntax error fix (rust-lang-nursery/reference#769)
- Fix incorrect pseudocode for #[repr(C)] struct alignment (rust-lang-nursery/reference#766)
- Replace "Field-Less" with "Fieldless" (rust-lang-nursery/reference#768)
- Removed repeated word (rust-lang-nursery/reference#767)
- Update for change in const lint name. (rust-lang-nursery/reference#764)
- semantic type -> resolved type (rust-lang-nursery/reference#761)
- add behavior change of relative paths without `self` in 2018 edition (rust-lang-nursery/reference#757)
- assignment operator expressions -> compound assignment expressions (rust-lang-nursery/reference#759)
## rust-by-example
3 commits in 32facd5522ddbbf37baf01e4e4b6562bc55c071a..db57f899ea2a56a544c8d280cbf033438666273d
2020-02-11 09:25:06 -0300 to 2020-02-18 17:46:46 -0300
- Minor typo fix in src/mod/visibility (rust-lang/rust-by-example#1309)
- Don't suggest Into implements a reverse conversion (rust-lang/rust-by-example#1307)
- Improve grammar in example of 'in let' section (rust-lang/rust-by-example#1308)
## embedded-book
2 commits in b2e1092bf67bd4d7686c4553f186edbb7f5f92db..b81ffb7a6f4c5aaed92786e770e99db116aa4ebd
2020-01-30 08:45:46 +0000 to 2020-02-27 08:06:04 +0000
- Setting output to `high` needs a `true` argument (rust-embedded/book#227)
- Add licence notes to index.md (rust-embedded/book#226)
|
|
Clean up unstable book
- #58402's feature was renamed to `tidy_test_never_used_anywhere_else` and it is now used for tidy only
- `read_initializer` link is wrong and the doc should be auto-generated so removed
- Add dummy doc for `link_cfg`
- Stop generating `compiler_builtins_lib` doc in favor of b8ccc0f8a60ac16fdc00f4b2e36e1a5db8b78295
- Make `rustc_attrs` tracking issue "None"
|
|
|
|
|
|
|
|
rename feature to const_eval_limit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=Mark-Simulacrum
rustc_session: allow overriding lint level of individual lints from a group
Fixes #58211 and fixes rust-lang/rust-clippy#4778 and fixes rust-lang/rust-clippy#4091
Instead of hard-coding the lint level preferences (from lowest to highest precedence: `lint::Allow -> lint::Warn -> lint::Deny -> lint::Forbid`), the position of the argument in the command line gets taken into account.
Examples:
1. Passing `-D unused -A unused-variables` denies everything in the lint group `unused` **except** `unused-variables` which is explicitly allowed.
1. Passing `-A unused-variables -D unused` denies everything in the lint group `unused` **including** `unused-variables` since the allow is specified before the deny (and therefore overridden by the deny).
This matches the behavior that is already being used when specifying `allow`/`deny` in the source code.
|
|
|
|
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.
|
|
Generator Resume Arguments
cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974
Blockers:
* [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069)
* [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162)
* [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901)
* [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137)
Follow-up work:
* Change async/await desugaring to make use of this feature
* Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
|
|
Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.
|
|
doc fix on doc attribute
None
|
|
|
|
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.
|
|
|
|
|
|
|
|
Update rustc-guide
r? @ghost
CC: @rust-lang/wg-learning
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
