| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This diff will look better once bors takes care of https://github.com/rust-lang/rust/pull/15183
@brson and I talked about it, and, if I commit this skeleton, I can submit PRs for each portion, without doing this silly "builds on previous PRs" stuff, and it shouldn't cause conflicts.
This lays out what I think the guide should cover, and in what order. I haven't picked a cohesive project yet that shows all this off, but I think this progression of concepts is appropriate.
|
|
zookoatleastauthoritycom/rust/13570-add-see-below-to-a-reference-to-a-new-concept-2, r=huonw
This is the same patch as submitted to https://github.com/rust-lang/rust/issues/13570 and https://github.com/rust-lang/rust/pull/14124, but with @pnkfelix's comment (https://github.com/rust-lang/rust/pull/14124#issuecomment-42797536) addressed, and with reflow as a separate commit. I'm submitting it in case @steveklabnik hasn't yet merged a rewrite of the tutorial (https://github.com/rust-lang/rust/issues/13570#issuecomment-46864789), in which case this patch might as well be merged into the old tutorial.
|
|
|
|
Thanks @huonw
|
|
Thank you, @stormbrew!
|
|
@cmr rightfully points out that C macros are worse, and share the
same name.
|
|
Thanks @chris-morgan and @P1start! :heart:
|
|
Good call, @chris-morgan and @cmr!
|
|
Thanks @chris-morgan
|
|
Thanks @chris-morgan :heart:
|
|
Thanks @chris-morgan :heart:
|
|
Thanks @chris-morgan :heart:
|
|
Thanks @chris-morgan
|
|
Death to `here`!
Thanks @chris-morgan :heart:
|
|
What's funny about this one is that spellcheck caught it, but for
some reason didn't give me the right suggestion, so I assumed that it
wasn't in my dictionary. Oh well.
Thanks @P1start! :heart:
|
|
How could I forsake `rustdoc`? :sweat_smile:
Thanks @huonw.
|
|
Thanks @huonw :heart:
|
|
@chris-morgan and @huonw pointed out that even though the feature
is a proper noun, we're using it in a more generic sense here.
|
|
|
|
|
|
|
|
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
|
|
This is built on top of https://github.com/rust-lang/rust/pull/15162 . https://github.com/steveklabnik/rust/commit/cccae83d922f5aade2b7cca96579521cc35ced59 is the only new commit, you may want to look at that rather than the whole diff.
Writing our first Rust program together. This is the most crucial step, so I go to a fairly deep level of detail. Future sections will move more quickly.
|
|
This has my voice *very strongly*. I'm not sure if it's too much. I'd find it okay if I had to tone it back, and I don't want it to be _too strong_, but clinical docs are boring.
|
|
|
|
Let's write our first Rust program!
|
|
Fixes #11113.
|
|
|
|
|
|
|
|
Fixes #11113.
|
|
zookoatleastauthoritycom/rust/14148-Optimize-out-exhortations-about-being-careful-2, r=huonw
Yes, it is important to be careful, but repeated emphasis about it is probably
not helpful — it starts to sound like you came for a tutorial but found a
finger-wagging lecture.
Even after I removed a few of these comments, there are still several left in
the text. That's probably fine! A couple of mentions of how this is dangerous
and you ought to be careful may be a good reminder to the reader.
After making the edits, I reflowed the paragraphs that I had touched, using
emacs's "M-x fill-paragraph", with fill-column equal to 70.
|
|
|
|
This is because I observed someone reading the tutorial who thought they'd
missed something when they got to the mention of variable bindings.
This patch doesn't reflow the paragraphs so that you can see the semantic
change that I made, and a subsequent patch will reflow this paragraph.
Fixes https://github.com/rust-lang/rust/issues/13570.
|
|
Yes, it is important to be careful, but repeated emphasis about it is probably
not helpful — it starts to sound like you came for a tutorial but found a
finger-wagging lecture.
Even after I removed a few of these comments, there are still several left in
the text. That's probably fine! A couple of mentions of how this is dangerous
and you ought to be careful may be a good reminder to the reader.
After making the edits, I reflowed the paragraphs that I had touched, using
emacs's "M-x fill-paragraph", with fill-column equal to 70.
|
|
"as this document" should be "than this document"
|
|
In line with what @brson, @cmr, @nikomatsakis and I discussed this morning, my
redux of the tutorial will be implemented as the Guide. This way, I can work in
small iterations, rather than dropping a huge PR, which is hard to review. In
addition, the community can observe my work as I'm doing it.
This adds a note in line with [this comment][reddit] that clarifies the state
of the tutorial, and the community's involvement with it.
[reddit]: http://www.reddit.com/r/rust/comments/28bew8/rusts_documentation_is_about_to_drastically/ci9c98k
|
|
Fixes #14806
|
|
Rust by Example is far better.
Fixes #14380.
|
|
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes #6023.
[breaking-change]
|
|
|
|
If you define lang items in your crate, add `#[feature(lang_items)]`.
If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.
Closes #12858.
[breaking-change]
|
|
This does not yet change the compiler and libraries from `*T` to `*const T` as
it will require a snapshot to do so.
cc #7362
---
Note that the corresponding RFC, https://github.com/rust-lang/rfcs/pull/68, has not yet been accepted. It was [discussed at the last meeting](https://github.com/rust-lang/rust/wiki/Meeting-weekly-2014-06-10#rfc-pr-68-unsafe-pointers-rename-t-to-const-t) and decided to be accepted, however. I figured I'd get started on the preliminary work for the RFC that will be required regardless.
|
|
`for...in`.
Closes #14803.
If you used a structure literal after one of these keywords, surround it
in parentheses.
[breaking-change]
|
|
|
|
There were still Total{Ord,Eq} in docs and src/etc
|
|
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
Closes #13540.
|
|
Closes #8142.
This is not the semantics we want long-term. You can continue to use
`#[unsafe_destructor]`, but you'll need to add
`#![feature(unsafe_destructor)]` to the crate attributes.
[breaking-change]
|
|
There is no space between the TOC and the succeeding para.
See http://doc.rust-lang.org/guide-pointers.html for example.
|
