This is a port of rust-lang/rust#26007.

The following is actually a comment on that thread, describing the rules in question:

I've never commented on this bug it seems. These rules are indeed intentional and yes they are the result of an interplay between autoderef rules and prioritization. The algorithm is that we first arrange a series of steps which correspond to increasing amounts of deref operations. We will try these steps in order and stop at the first step for which we find methods. Within a given step, we will give inherent methods priority over trait methods.

This ordering is the result of a lot of experimentation and making changes to it will definitely cause massive breakage. Before 1.0, I did spend some time experimenting with different "cleaner" strategies, but abandoned it because they broke a lot of code and by and large made things work less well (i.e., more explicit * and &).

The exact algorithm:

• Assemble list of types found by repeatedly deref'ing, with the addition of a single "unsize" step.
  • Example: if receiver is Box<Vec<T>>, we would produce:
    • Box<Vec>
    • Vec (deref)
    • [T] (unsize)
• Iterate down that list, and for each type X:
  • Try with receiver of X (no adjustments), then &X (one autoref), then &mut X (one autoref-mut):
    • Search for inherent methods defined on the given type (X, &X, or &mut X)
    • If none found, search for extension methods

I am certainly not saying that this procedure is ideal, but we definitely can't cavalierly change it, and it has some nice properties. For example, if you have an &self method in an impl defined on T, that is equivalent in resolution order to a fn(self) method defined in an impl for &T.

An example of a change I tried to make which did not work was to search for impls defined directly on the type X and then apply the autoref by looking at how the method was defined. This seems cleaner, but it interacted quite poorly with Clone, since with the new rules, if you invoke clone() on an &T type, it would invoke the (no-op) impl of Clone for &T instead of invoking the Clone impl for T (which is what you want, and what we do today). That is, today, if the receiver has type &T, we will search for methods whose receivers are &T first -- and this matches the impl of Clone for T, since clone() is an &self method (whereas the impl of Clone for &T would match when we search for &&T).

So basically I think we have to document these rules but I wouldn't want to change them without careful consideration.

The issue mainly becomes phrasing this for the reference and finding the proper location for it.

As a guide, it may have these sections:

• Patterns (introduction)
• Wildcard pattern _
• Reference patterns & ...
• Tuple patterns (a, b, ...)
• Slice patterns [a, b, ..i, y, z]]
• Identifier patterns binding @ subpattern
• Literal patterns 1, 2, etc
• Range patterns 0..10
• Struct patterns Variant {a, b, ...}
• Tuple struct patterns Variant (a, b, ...)
• Box pattern
• Refutability
• Destructuring

Originally at rust-lang/rust#41060

The reference currently says the following for integer literals

The type of an unsuffixed integer literal is determined by type inference:
[...]
If the program context under-constrains the type, it defaults to the signed 32-bit integer i32.

This does however not work for some inherent methods of signed integer types:

trait A {
    fn what_type(&self);
}


impl A for i16 {
    fn what_type(&self) {
        println!("i16");
    }
}

impl A for i32 {
    fn what_type(&self)  {
        println!("i32");
    }
}

fn main() {
    let z = 1;
    z.what_type();
    //z.is_positive(); // <- uncomment this line
}

As you can see, z is under-constrained in this case. The compiler does the right thing and defaults to type i32, so calling the trait method what_type() works.

If you uncomment the inherent method call to is_positive(), z still is under-constrained in pretty much the same way as before, however, the compiler fails to default to i32 and instead prints

error: no method named `is_positive` found for type `{integer}` in the current scope

Also note that the reference says

If an integer type can be uniquely determined from the surrounding program context, the unsuffixed integer literal has that type.

But the following example show that the order of statements is important:

fn one() { // compiles
    let a = 0;
    take_some(a);
    a.is_positive();
}

fn two() { // does not compile
    let a = 0;
    a.is_positive();
    take_some(a);
}

fn take_some(var: i32) {
    // do nothing
}

I think floating-point literals have the same issue, but I haven't checked.

rust-lang/rust#39255 and rust-lang/rust#40985 may be related.

This is not a Cargo issue. Cargo is working fine. This is a description of a discrepancy that I have found between Cargo's behavior and the v2 Book.

In section 1.2 the book says:

Cargo has generated a "Hello World!" for you, just like the one we wrote earlier! So that part is the same.

However, running the command cargo new <crate_name> to create a new Cargo project does not, in fact, generate this "Hello World" file. It instead generates a lib.rs that does not compile to an executable, but rather to a variety of library resource files. To clarify:

• Expected (according to docs): Cargo generates a main.rs containing Hello World code
• Actual: Cargo generates a lib.rs with no "concrete" code at all
• Resolution: Update the docs to indicate that Cargo will not, in fact, generate this file

Since any Rust impl is going to need to be semantically equivalent to the desugaring that rustc does, we should document what the desugarings are in the reference.

The for loop one is documented already in the std lib.

We need to run on nightly, but not allow nightly features. This is because this stuff now lands in rust master, so we need to be able to document newly stable features, but before they actually hit stable.

I plan on writing a script we can run in CI to check this, but if anyone is interested in helping out, that'd be great!

Moved from rust-lang/rust#5551

The section on "static items" (formerly entitled "constants") refers to some class of "constant expressions", but we have not defined what these are.

(I think catamorphism has noted this via comments in a few issues I have seen, but I have not seen an actual Issue for this topic; so I am promoting it to a full fledged issue.)

In particular, if we need a subgrammar, or some other sort of static analysis to classify the constant expressions correctly, then we should document it.

Since Rust Reference underwent the split by chapters, all the links in the wild, like in answers on StackOverflow, are effectively dead, because they don't lead to the relevant parts of Reference anymore.

I realise the problems of handling url fragments, but couldn't a migration page be generated? Like http://doc.rust-lang.org/reference.html#tuple-types should go to a place in the page which says "This section has been moved to https://doc.rust-lang.org/reference/types.html#tuple-types", and so on for every anchor in the old reference page.

This would be much more helpful, as searching whatever chapters possibly contain the relevant data manually isn't quite easy.

In the section on type coercions, the list of allowed coercions looks quite wonky (on a recent version of Chrome):

For reference, the rendering on GitHub itself is fine.
I compared the generated HTML and for the first few items, it's identical (for the last few it's only syntax highlighting differences), so it seems like this is a CSS issue (with mdbook?).

Consider the following example:

enum Foo {
    A,
    B,
    C
}

fn main() {
    println!("{}", Foo::A as usize);
    println!("{}", Foo::B as usize);
    println!("{}", Foo::C as usize);
}

The current behavior is that Foo members get casted to an increasing sequence starting from 0. Although that seems to be the most reasonable default, it should be documented to make clear that it won't be changed in the future.

Moved from rust-lang/rust#34729

After a short debate on the IRC over whether true as i32 is guaranteed to be 1, and false as i32 is guaranteed to be 0, I think that the semantics section on casts should explicitly describe what a bool as integer_type cast does.

Because, uh, they aren't documented.

Explain nouns and names specific to rust.

See title.

Some of the questions that I would hope it would answer are:

• All of the usual things about building and contributing.
• If and how are larger contributions and rewrites accepted?
• What are the main goals for improving the reference?

Migrated from rust-lang/rust#38193

In Rust it is possible to define items inside functions. It is natural to ask whether it's possible to import these items with a use statement out of the function, like so:

pub fn func() {
    pub struct Struct;
}

use func::Struct;

The Rust Reference does not give any explicit answer on whether such a construct is valid. In particular, it says "Every item has a canonical path within its crate," which suggests the path of Struct in the example above is func::Struct, and it doesn't indicate such items are private. Only by running the code I could tell that this construct is not valid.

I suggest the Rust Reference clarify either in its discussion of paths, functions, or item statements that it's impossible to import an item from an item statement.

Migrated from rust-lang/rust#36427

For references, see

• StackOverflow Answer
• TypeCk ReadMe

Some comments in IRC today brought to my attention that you can add to the stock attributes that are pasted into doctests. They extrapolated from these lines in libstd and were able to add #![doc(test(attr(deny(warnings))))] to their own crate to add a #![deny(warnings)] to all their doctests. It would be nice to investigate how rustdoc handles these extensions to the doc attribute and add it to the line about it in the Attributes chapter.

Migrated from rust-lang/rust#38011

Default type parameters (e g struct Foo<A = u32>(A)) is a language feature, but they are not mentioned in the language reference.

It would be nice if such a reference also mentioned the tricky semantics around how it interacts with inference, as mentioned here.

Currently the reference says:

The IEEE 754-2008 binary32 and binary64 floating-point types: f32 and f64, respectively.

Now is it legal per the reference to port Rust to to platforms that don't implement IEEE 754-2008 but only IEEE 754-1985, and which can deviate in their floating implementation from IEEE 754-2008? Some MIPS platforms come to my mind that implement signaling NaNs differently.

The Constant Expression section currently contains a bulleted list of which expressions are constant and contains one interesting line:

Paths to statics, so long as only their address, not their value, is used. This includes using their value indirectly through a complicated expression. *

That asterisk says that's only true for static items. As such, it's sort of out of place in the Constant Expression section. Instead, the Static Item section should say that it allows constant expressions plus referencing statics by address. The second sentence is also hard to read, and should have an example with it. It should also say "complex" not "complicated".

They're for C interopt, but they aren't documented anywhere in the reference.

Add a warning to the top of the page detailing that the reference is currently at a best-effort stage, like the warning for the second edition Rust-book (see image).

The text of this warning should contain the following or similar text, but with proper linking:

"For now, the Rust reference is a best-effort document. We strive for validity and completeness, but are not yet there. At some point in the future, the docs and lang team will work together to figure out how best to do this. Until then, this document is a best-effort attempt. If you find something wrong or missing, file an issue or send in a pull request."

The equivalence is wrong because the scope of the expression in the predicate has to live as long as the consequent because of the ability to ref in the pattern.

Or something like that.

Hello,

I don't find any documentation about rust expression precedence rules in the book and reference. Could someone point me to it if it exists? If not, should it be added to the reference? Related forum post and rust issue #21799 and #44288.

Explanation:
In cases where expression parsing is ambiguous, there must be some expression precedence rules. For operator expressions it is documented in the reference as operator precedence. But for general expressions it is unclear, in ambiguous cases, which expression type takes precedence over the other. Two examples: 0..10.some_method() (range expr vs method call expr), &some_struct.some_method() (operator expr vs method call expr).

Thank you

This issue tracks the work in documenting the grammar.

Since the grammar is very incomplete and I'm willing to complete it, I thought it would be better to do this inside the reference, alongside each item of the language.

Progress:

• Create a script to join the scattered grammar in one place.
• Lexical productions
  • Keywords PR #97
  • Identifiers PR #89
  • Comments PR #85
  • Literals
    • Char PR #121
    • String PR #121
    • Raw string PR #121
    • Byte PR #121
    • Byte string PR #121
    • Raw byte string PR #121
    • Integer PR #108
    • Float PR #109
    • Bools PR #110
  • Symbols draft
  • Paths draft
• Syntax productions
  • Crates PR #87
  • Items
    • Visibility PR #90
    • Modules PR #143
    • Extern crate PR #144
    • Use declaration PR #145
    • Static item
    • Const value
    • Functions draft
    • Type aliases
    • Enums
    • Structs
    • Unions
    • Extern blocks
    • Traits draft
    • Implementations draft
    • Const functions
    • Extern functions
  • Attributes PR #88
  • Statements
    • Item declarations
    • let statements
    • Expression statements
  • Expressions draft
    • Literal #138
    • Path
    • Tuple
    • Struct
    • EnumerationVariant
    • Block #136
    • Method call
    • Field access #158
    • Tuple indexing
    • Call expression #134
    • Closure #135
    • Array expression #133
    • Indexing expression #133
    • Range expression #142
    • Operator expression #141
      • borrow
      • dereference
      • error propagation
      • negation
      • arithmetic and logical
      • comparison
      • lazy boolean
      • typecast
      • assignment
      • compound assignment
    • Grouped expression #141
    • Loop expressions #139
      • loop
      • while
      • while let
      • for
      • break
      • continue
    • if #137
    • If let #137
    • match
    • return #140
  • Patterns draft
    • Wildcard
    • Reference
    • Struct
    • TupleStruct
    • Tuple
    • Slice
    • Identifier
    • Path
    • Literal
    • Range
    • Box
  • Types
    • path type
    • qualified path type
    • tuple type
    • array type
    • slice type
    • reference type
    • inferred type
    • raw pointer type
    • function pointer type
    • trait object type
    • impl trait type
    • never type (divergent functions)
    • parenthesized type
  • Macros
    • Macro definitions
    • Macro invocations (and the places they can appear, scattered in other grammar items)

From language items: "The set of language items is currently considered unstable. A complete list of the built-in language items will be added in the future."

#13 documents which casts are possible, as well as the semantics of the casts that don't involve pointers. For pointers it's not clear if a complete set of semantics can be given until the unsafe guidelines/memory model are determined, but maybe some statements can be made.

Many sections of the new split up reference don't contain any content at all at the top level, or contain only little text. If you are reading it in full screen, more than half of the screen is whitespace. It would be really nice to have a single page mode, so that you don't have to click all the time, and so that ctrl+f and friends works.

Feature is being stabilized in 1.18.

It seems like it doesn't happen as often as https://doc.rust-lang.org/nightly/reference/ might lead you to expect.

The page https://doc.rust-lang.org/reference/macros.html contains links to "Macros" and "Procedural Macros". Presumably these should point to the subsections immediately below it in the reference - "Macros By Example" and "Procedural Macros". But instead they are old links to the Book, which go to the "The Rust Programming Language Has Moved" page. The only way to navigate to the intended subsections is to notice them in the navigation sidebar and click on them there.

It would be good to fix these links to go to the right place.

Migrated from rust-lang/rust#34817

I used pub const FOO: &'static Bar = &Bar { // crate-private stuff here ... }; in a crate. Within that crate, FOO as *const Bar was consistently the same address. However, when used in another crate, FOO as *const Bar became another address.

Apparently what's happening is that the RHS of const is inlined but within a given crate (effectively allowing a crate to inline stuff that's private to another crate), duplicates are later coalesced when making the values being referred to into the data section of the object file.

What I thought was supposed to be happening was this:

I expected the Bar { // crate-private stuff here ... } bit to be evaluated once in the crate where the constant was declared and the result getting uniquely baked into the data section of the object file. I then expected the value that gets inlined at contant use time to be the address of that unique location.

Especially considering that this appears to result in a constant address within a crate but blows up when the constant is used in another crate, it would be useful for the Book and the Reference to spell out more clearly that the constant isn't just the reference value of the right-hand-side expression but the entire right-hand-side expression itself and explicitly warn about the instantiations of the constant expression getting coalesced on a per-crate basis, which gives the appearance of the reference being the value of a uniquely evaluated expression rather than the expression itself as long as you are only testing within a single crate.

The standard library documentation documents what version that various types, functions, and what not are stabilized. Since there's no "API docs" for features, other than this reference, should we be documenting when language features are stabilized into the reference?

Originally filed by @SimonSapin at rust-lang/rust#40087

It looks like https://doc.rust-lang.org/nightly/reference.html hasn’t been updated yet as of this writing, but in my local copy of the docs reference.html says “We've split up the reference into chapters. Please find it at its new home here.” with a link to reference/index.html.

This new format has a side bar with a table of content, but that ToC has coarser granularity than it used to. As far as I can tell, it has a link for each “chapter” (part of the book that requires navigation to another URL), but I can’t find a ToC for sections within a chapter. reference/expressions.html for example has many sub-sections, to a per-chapter ToC would help a lot.

This is probably a feature request for tool that generates this kind of documentation, but I’m not sure what it is. I’ve vaguely heard of rustboot and mdbook, is this one on these? Are they related? Which issue tracker should be used?

CC @steveklabnik

Overview

Tracking issue for RFC #1636. Let's make the reference a reliable resource for all Rustaceans! 🎉 This might seem intimidating, but the reality is that if we just chip away at it together, we'll be done in no time!

I'm going to be updating this parent issue with a master list of items that need to be documented in the reference as I find them. Quoting the RFC text:

Updating the reference should proceed stepwise:

1. Begin by adding an appendix in the reference with links to all accepted RFCs which have been implemented but are not yet referenced in the documentation.
2. As the reference material is written for each of those RFC features, remove it from that appendix.

Note that step 1 should be fairly straightforward; the main issue will be assembling the list of accepted-and-implemented-but-undocumented RFCs. (Also, any RFCs accepted before RFC 1636 but not yet stabilized should presumably be documented under the rules it establishes, but if I'm wrong about that, someone should let me know and I'll include them as well.)

Also, a pre-emptive apology for the scale of this issue description. We have let things get into a rough spot. (I plan to create documentation issues for each of the required items below once this list is completed, so this thread doesn't become completely unmanageable.)

Status: Last updated May 13, 2017, now processing a copy of @Eh2406's wonderful gist based on @matthewjasper's fork here.

"How Can I Help?"

For right now, since you can't submit updates to the issue directly, there are two major ways you can help:

1. Write documentation. For the RFCs already triaged and filed under the major section C. Documentation Needed and specifically the subsection 2. Write reference material for undocumented, implemented, stabilized RFC features below, you can open a pull request and reference this issue in its description. I'll keep an eye out for inbound links here and add those links to the relevant items, and once they're merged, we'll mark that item as done.

2. Triage issues. Work the gist where I'm tracking the triaged-state, specifically looking at the Not Reviewed at All and Stabilized, Not Reviewed sections and evaluating whether they're documented or not. You can fork the gist and I will keep an eye out, checking roughly daily, for any changes to merge back into that document. (Do take a look at what others may have forked it so you don't duplicate work needlessly!) I'll then pull those over into this master issue.

   When working through those, if you determine that they're already documented, please leave a note (and link!) on your copy of the gist as to where so I can link it in this document. That dramatically decreases the time it takes me to confirm it—I double-check all of these.

A. Tracking

(This section will go away entirely once all of the RFCs have been flagged for documenting or marked documentation-not-needed here.)

RFCs reviewed

Currently: 115/301

RFCs unreviewed

B. Status unclear

Some of these are still in-flight; and some of them are just the kind of thing that I don't even fully grok yet well enough to see if they're documented. For these, unchecked means "status unknown"; checked means "status known and added to the latter bits appropriately."

• #0019: Opt-in built-in traits (OIBITs)
  • status query

C. Documentation needed

0. Accepted, not-yet-stabilized, undocumented RFCs

0.1. Document implemented, unstable RFCs

These should be considered the highest priority for documentation, as these are issues which fall under the rest of the rules of [RFC #1636], in that they need to be documented before stabilization. (That will presumably just happen before stabilizing as usual, but I'm including them here for completeness.)

• #0086 plugin-registrar API
• #0202: subslice syntax change -- implemented here, not stabilized; see discussion of [#405] below under C.0.2.
• #1131: Add an expect intrinsic
• #1358: repr_align – implementation is in-progress, not yet landed on nightly
• #1624: loop_break_value
• #1665: Windows subsystem support

0.2. Track accepted, not-yet-implemented or implementation-in-progress, undocumented RFCs

These will eventually require documentation, but as they aren't even (fully) implemented yet, there is no urgency here.

• #0066: Better temporary lifetimes – tracking issue
• #0495: Array/slice/subslice pattern adjustments – tracking issue
• #0803: type ascription on expressions – tracking issue
• #1199: SIMD infrastructure (Note: this is stalled; it may eventually be superceded by a further RFC.)
• #1214: Projections, lifetimes, and well-formed-ness
• #1398: Standard and custom allocator API – tracking issue
• #1432: {Vec,String}::splice – tracking issue
• #1566: Procedural macros – tracking issue
• #1576: literal fragment specifier for macro_rules! – tracking issue
• #1590: lifetime specifier for macro_rules – tracking issue
• #1845: shared_from_slice – tracking issue
• #1860: add ManuallyDrop to core – tracking issue
• #1869: eprint! and eprintln! – tracking issue
• #1884: unstable sort in libcore – tracking issue

1. List accepted, implemented, already-stabilized, undocumented RFCs

This list can be added directly to a newly(-to-be)-created appendix to the Reference.

• Create the appendix (once finished, this list should do just fine, perhaps with some massaging for descriptiveness)

  • #0040: libstd-facade – there is one reference to the facade, in 6.3.13 Compiler Features under a discussion of #[no_std], but no explanation of its meaning. Nor, as far as I can tell, do the relevant sections of the standard library documentation explain this.
  • #0048: Trait reform – some pieces of this are partially documented (the use of Self), but others aren't at all: coherence and orphan rules are covered nowhere. (Currently, the writeup here seems to be the best source on coherence?)
  • #0049: Allow attributes on match arms. – the underlying idea is documented in 6.3 Attributes but the applicability to internal items is never specified.
  • #0131: Some but not all of the flags are documented in 6.3.8 Conditional compilation
  • #0132: Unambiguous function call syntax – not even mentioned
  • #0558: require parentheses for chained comparisons
  • #0560: Integer overflow not unsafe, documented with a reference to the RFC but requires further details
  • #1717: dllimport, one element mentioned but not explained at 6.3.5 FFI attributes
  • #1721: define crt_link
  • #1725: define unaligned_access

2. Write reference material for undocumented, implemented, stabilized RFC features

Each of the features listed above in (1) needs to be documented more formally in the reference.

• #0040: libstd-facade
• #0048: (#5) Trait reform, requires documenting coherence and orphan rules (overlaps with Coherence and Orphan rules below in §3)
• #0049: Allow attributes on match arms: specify applicability to internal items
• [#71]: (#13) Allow blocks in constants
• #0131: Target specification – some but not all of these are in 6.3.8
• #0132: Unambiguous/universal function call syntax – not even mentioned
• #0179: &mut patterns – symmetry of pattern syntax not documented
• #0558: (#41) require parentheses for chained comparisons – the requirement is not documented in the reference
• #0560: Integer overflow not unsafe, documented with a reference to the RFC but requires further details
• #1717: dllimport
• #1721: crt_link
• #1725: unaligned_access

3. Update out-of-date/incomplete sections of the reference

• List of language items

  The set of language items is currently considered unstable. A complete list of the built-in language items will be added in the future.

• Coherence

• Orphan rules (#5)

• Lifetime elision

D. Documentation not needed

0. Already documented

1. Retired

2. Removals

3. Parser-specific

4. Process and conventions

5. Non-language features

Note: I've just copied over the original issue as it was—wholesale. Note that some of the links here referencing things as "already documented" will degrade given the new structure of the book.

https://doc.rust-lang.org/nightly/reference/tokens.html#integer-literals says

If the program context under-constrains the type, it defaults to the signed 32-bit integer

and https://doc.rust-lang.org/nightly/reference/tokens.html#floating-point-literals says

If the program context under-constrains the type, it defaults to f64

I don't believe this is true, it's if there are no constraints, not under-constraints.

This is one to get lang team sign-off for.

A great strength of the old one-page reference was that you could search it. Full text search would be great. See also https://github.com/azerupi/mdBook/issues/51.

The Nomicon and the Reference don't say that dereferencing a misaligned pointer is undefined behavior, but I certainly would expect it to be. Checked with @gankro on IRC and he agreed.

To verify, I compiled the following:

extern {
fn f() -> *const i32;
}

fn main() {
println!("{}", unsafe { *f() + 1 });
}

This produces LLVM IR containing the following code for the call:

%3 = tail call i32* @f()
%4 = load i32, i32* %3, align 4
%5 = add i32 %4, 1

The align 4 in the load instruction indicates that LLVM should assume that the pointer is aligned on a four-byte boundary. The LLVM IR docs for load say, "Overestimating the alignment results in undefined behavior."

See also: rust-lang/nomicon#15

This is a port of rust-lang/rust#34968.

Spawned off of rust-lang/rust#34932 (comment)

If you put the inner attribute #![cfg(..)] at a crate root, this (apparently) causes an empty crate to be generated. I.e., it is as if the crate itself still exists, but all of its contents have disappeared.

This is slightly different than the behavior of #![cfg(..)] elsewhere (e.g. in a mod item), where such an inner attribute will cause the whole item to be omitted from the AST, rather than just causing the contents of the item to be omitted.

I don't see any mention of this corner case in the Rust documentation for Conditional Compilation, here: https://doc.rust-lang.org/book/first-edition/conditional-compilation.html

Since the second edition of the book doesn't have a dedicated section to conditional compilation, it would be worth elaborating on it here. Whether or not that includes porting some of that discussion out is another matter. This issue was more about how an inner cfg attribute creates an empty crate when used in the crate root, but removes the item entirely if used anywhere else. (This is what winapi does to only build on windows, for example.)

This is documented in the book's first edition, but it doesn't seem to be in the reference at all. Just a mention in the Drop trait section, maybe copy-pasting the example from the book too, would suffice.

refiling rust-lang/rust#38211

There are a few aspects of "static" (non-closure) functions that I find useful to know but I can't seem to locate in the docs:

• They all implement Copy.
  • And they don't implement Clone (is this unusual?)
• They automatically implement the respective function call traits Fn, FnMut and FnOnce.
  • And since they don't have an environment... they are equivalent?

I think it might be appropriate to have an entry in the std/core documentation with this. Not sure if a new "primitive" page would be appropriate for it.

Plans to add a mergebot for this repo? I've been pretty satisfied with https://bors-ng.github.io/, though I understand if we just want to use the same homu instance in charge of rust-lang/rust

Currently the section for the trait just says The Sized trait indicates that the size of this type is known at compile-time.. Should expand on that more.

Should pull in the information on https://doc.rust-lang.org/std/marker/trait.Sized.html at a minimum.

Migrated from rust-lang/rust#34803

Rust appears to support #[cfg(feature = "foo")] to control optional features: Cargo doc.

The Rust reference on cfg does not mention feature: nightly doc.

Migrated from rust-lang/rust#29936

We have this paragraph (source)

The following is a list of behavior which is forbidden in all Rust code, including within unsafe blocks and unsafe functions. Type checking provides the guarantee that these issues are never caused by safe code.

First sentence (these issues are not possible in Rust) seem to conflict with the second one (these issues are not possible in safe Rust).

In many locations in the Reference document, I see these lines:

# fn main() {}

Like here:
https://doc.rust-lang.org/stable/reference/visibility-and-privacy.html

Looks like they are supposed to be comment (// ...) and would need a mass update through out the whole repo.

Many code blocks aren't correctly started with ```rust so don't have syntax highlighting or lines starting with # removed:

The Unstable Book is going to document all the currently unstable features. Is it worth keeping the content in this section around? https://doc.rust-lang.org/nightly/reference/attributes.html#compiler-features

Relevant issue: #9

Originally at rust-lang/rust#34968

Spawned off of rust-lang/rust#34932 (comment)

If you put the inner attribute #![cfg(..)] at a crate root, this (apparently) causes an empty crate to be generated. I.e., it is as if the crate itself still exists, but all of its contents have disappeared.

This is slightly different than the behavior of #![cfg(..)] elsewhere (e.g. in a mod item), where such an inner attribute will cause the whole item to be omitted from the AST, rather than just causing the contents of the item to be omitted.

I don't see any mention of this corner case in the Rust documentation for Conditional Compilation, here: https://doc.rust-lang.org/book/conditional-compilation.html

As per #111, we don't yet have a story on whether we want to document unstable aspects of Rust, and if we do, how do we want to do so?