about summary refs log tree commit diff
path: root/src/doc
AgeCommit message (Collapse)AuthorLines
2020-02-25Name resolution: Add intro sectionPhilipp Hansch-1/+18
2020-02-20Add documentation for the `-Zself-profile-events` flagWesley Wiser-0/+74
2020-02-20add back linkMark Mansi-0/+2
2020-02-20update glossaryMark Mansi-1/+2
2020-02-20create a separate chapter on arenas/interningMark Mansi-107/+119
2020-02-20mention tidy blessMark Mansi-0/+3
2020-02-20tidy runs rustfmt checkMark Mansi-1/+2
2020-02-20document ./x.py fmtMark Mansi-0/+9
2020-02-19spit of type folder and generics subchapters (#586)Who? Me?!-248/+251
2020-02-18fix linkMark Mansi-1/+1
2020-02-18Update section following current stateYuki Okushi-5/+4
2020-02-17Add documentation for the `-Zself-profile` flagWesley Wiser-0/+47
2020-02-16Auto merge of #67885 - tobithiel:fix_group_lint_allow_override, ↵bors-0/+20
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.
2020-02-15Add links to the rustc docs (#578)LORIS INTERGALACTIQUE-19/+31
2020-02-14Fix linkYuki Okushi-1/+1
2020-02-14Add link to `rustc::mir::Location` (#579)Youngsuk Kim-1/+2
2020-02-13Update books.Eric Huss-0/+4
2020-02-12Correction of type name (#576)Youngsuk Kim-2/+2
`ConstraintSet` => `OutlivesConstraintSet`
2020-02-12Minor typo correctionLoris-intergalactique-1/+1
2020-02-11Rollup merge of #68824 - ajpaverd:cfguard-rustbuild, r=Mark-SimulacrumDylan DPC-0/+34
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
2020-02-10minor typo fixYoungsuk Kim-1/+1
2020-02-10minor typo fixYoungsuk Kim-1/+1
2020-02-10Enable Control Flow Guard in rustbuildAndrew Paverd-0/+34
2020-02-10Update sanitizers documentation (#562)Tomasz Miąsko-19/+25
2020-02-07Rollup merge of #68164 - tmiasko:no-sanitize, r=nikomatsakisDylan DPC-0/+29
Selectively disable sanitizer instrumentation Add `no_sanitize` attribute that allows to opt out from sanitizer instrumentation in an annotated function.
2020-02-06Added example of icebreakers-cleanup-crewFelix S Klock II-0/+1
(I figure its low cost to just list all the possible pings, compared to the cost of people getting the command wrong or not even knowing the full set of teams possible.)
2020-02-06Rollup merge of #68791 - mark-i-m:proper-linkcheck, r=ehuss,JohnTitorDylan DPC-0/+0
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.
2020-02-06Rollup merge of #68524 - jonas-schievink:generator-resume-arguments, r=ZoxcDylan DPC-15/+11
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)
2020-02-05mir: begin documenting user variable debuginfo. (#571)Eduard-Mihai Burtescu-10/+22
2020-02-05Selectively disable sanitizer instrumentationTomasz Miąsko-0/+29
Add `no_sanitize` attribute that allows to opt out from sanitizer instrumentation in an annotated function.
2020-02-05Rollup merge of #68846 - king6cong:doc-fix, r=GuillaumeGomezDylan DPC-1/+1
doc fix on doc attribute None
2020-02-05doc fix on doc attributeking6cong-1/+1
2020-02-04Rollup merge of #68282 - tmiasko:sanitizer-example, r=steveklabnikDylan DPC-2/+10
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).
2020-02-03update rustc-guideMark Mansi-0/+0
2020-02-02Add a mention of the new `-Zllvm-time-trace` flagWesley Wiser-0/+2
2020-02-02Update READMEWho? Me?!-2/+2
2020-02-03Fix broken links (#570)Who? Me?!-6/+6
2020-02-02Add a resume type parameter to `Generator`Jonas Schievink-15/+11
2020-01-31Install robots.txt into rust-docs tarballsMark Rousskov-1/+0
2020-01-30use cargo installMark Mansi-25/+2
2020-01-30Add an example PR to join the Cleanup Crew ICE-BreakersSantiago Pastorino-0/+1
2020-01-29Replaced simple comment with doc commentLeSeulArtichaut-1/+1
2020-01-29Auto merge of #68572 - tmiasko:sanitizer-use-after-scope, r=nikicbors-0/+74
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.
2020-01-28Auto merge of #68529 - TimDiekmann:rename-alloc, r=Amanieubors-1/+1
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
2020-01-28stabilize the debug_map_key_value featureAshley Mannix-9/+0
2020-01-27Rename `Alloc` to `AllocRef`Tim Diekmann-1/+1
2020-01-27Auto merge of #68122 - Centril:stabilize-transparent-enums, r=petrochenkovbors-93/+0
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.
2020-01-27Add use after scope example to the unstable bookTomasz Miąsko-0/+74
2020-01-25Instrument C / C++ in MemorySanitizer exampleTomasz Miąsko-2/+10
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.
2020-01-23add cleanup crew (#556)Niko Matsakis-0/+115
* add cleanup crew * update the text about carog-bisect-rustc etc * Update src/ice-breaker/cleanup-crew.md Co-Authored-By: lqd <remy.rakic+github@gmail.com> * finish the 3rd section * fix typo * clarify when you need to find PR range * add link to zulip stream Co-authored-by: lqd <remy.rakic+github@gmail.com>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 10:15:30 +0000