| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It was moved in #29538.
|
|
Also remove a "finally" in the section about building for release
to make it feel a bit friendlier.
|
|
r? @steveklabnik
|
|
|
|
r? @alexcrichton
|
|
Closes #31103
r? @steveklabnik
|
|
|
|
r? @steveklabnik
|
|
When I read the book, the following sentence of the reference documentation helped me greatly to understand slices:
"Slices are a view into a block of memory represented as a pointer and a length."
In this commit, I tried to integrate the gist of that into the slice section inside of "primitive-types.md". I am not a native speaker, so feel very free to improve the wording.
r? @steveklabnik
|
|
|
|
|
|
|
|
Closes #31103
|
|
|
|
|
|
Fix spacing style of `T: Bound` in docs
The space between `T` and `Bound` is the typical style used in code and
produced by rustdoc's rendering. Fixed first in Reflect's docs and then
I fixed all occurrences in docs I could find.
|
|
The space between `T` and `Bound` is the typical style used in code and
produced by rustdoc's rendering. Fixed first in Reflect's docs and then
I fixed all occurrences in docs I could find.
|
|
|
|
|
|
Add support to use functions exported using vectorcall.
This essentially only allows to pass a new LLVM calling convention
from rust to LLVM.
```rust
extern "vectorcall" fn abc(param: c_void);
```
references
----
http://llvm.org/docs/doxygen/html/CallingConv_8h_source.html
https://msdn.microsoft.com/en-us/library/dn375768.aspx
|
|
* ref: Issue #30825
Small punctuation change in "Crates and Modules".
|
|
Also, whitespace fixes
|
|
This feature is partially stabilized, so describe each part in the appropriate place.
r? @alexcrichton @brson
It would be nice to backport this to beta, since this is the first release where this is true. I try really hard to not do doc backports, but this isn't very large, and might be worth making an exception, I dunno.
|
|
This also repeats the case analysis used.
|
|
Also, whitespace fixes
|
|
This feature is partially stabilized, so describe each part in the appropriate place.
|
|
r? @steveklabnik
|
|
Fixes #30819
|
|
|
|
|
|
Fixes #30819
|
|
r? @steveklabnik
|
|
|
|
When I read the book, the following sentence of the reference documentation helped me greatly to understand slices:
"Slices are a view into a block of memory represented as a pointer and a length."
In this commit, I tried to integrate the gist of that into the slice section inside of "primitive-types.md".
|
|
|
|
Doing so is considered weaker writing. Thanks @Charlotteis!
Fixes #28810
|
|
|
|
I'm working my way through TRPL beginning at "Syntax and Semantics" as was recommended in a previous version.
I'm expecting the chapter to incrementally build up my knowledge of the language section by section, assuming no prior Rust experience. So it was a bit of a speed-bump to encounter references and the vector type in a code example long before they had been defined and explained.
Another commit in this PR tries to make consistent what is a "chapter" of TRPL versus a "section." Just a nit-pick, but not thinking about that stuff keeps my focus on the important material.
My background: Python programmer since ~2000, with moderate exposure to C, C++, assembly, operating systems, and system architecture in university several years ago.
For your kind consideration, feel welcome to use or drop or rework any part of this.
|
|
|
|
|
|
|
|
In a straight-through read of "Syntax and Semantics," the concept of a
"reference" is used here before it is explained. Mention that and link to
the section explaining references.
|
|
In a straight-through read of "Syntax and Semantics," the first time we
meet a generic, and the first time we meet a vector, is when a Vec<T> shows
up in this example. I'm not sure that I could argue that the whole section
should appear later in the book than the ones on vectors and generics, so
instead just give the reader a brief introduction to both and a promise to
follow up later.
|
|
Declare what LIFO stands for
|
|
Fixes #30254
|
|
I noticed the alignment was off in the error handling part of the book. This was caused because two tabs had crept into the file. I have changed these for spaces.
|
|
|
|
Declare what LIFO stands for
|
|
This also repeated the case analysis used.
|
|
Some history:
While getting Rust to 1.0, it was a struggle to keep the book in a
working state. I had always wanted a certain kind of TOC, but couldn't
quite get it there.
At the 11th hour, I wrote up "Rust inside other langauges" and "Dining
Philosophers" in an attempt to get the book in the direction I wanted to
go. They were fine, but not my best work. I wanted to further expand
this section, but it's just never going to end up happening. We're doing
the second draft of the book now, and these sections are basically gone
already.
Here's the issues with these two sections, and removing them just fixes
it all:
// Philosophers
There was always controversy over which ones were chosen, and why. This
is kind of a perpetual bikeshed, but it comes up every once in a while.
The implementation was originally supposed to show off channels, but
never did, due to time constraints. Months later, I still haven't
re-written it to use them.
People get different results and assume that means they're wrong, rather
than the non-determinism inherent in concurrency. Platform differences
aggrivate this, as does the exact amount of sleeping and printing.
// Rust Inside Other Languages
This section is wonderful, and shows off a strength of Rust. However,
it's not clear what qualifies a language to be in this section. And I'm
not sure how tracking a ton of other languages is gonna work, into the
future; we can't test _anything_ in this section, so it's prone to
bitrot.
By removing this section, and making the Guessing Game an initial
tutorial, we will move this version of the book closer to the future
version, and just eliminate all of these questions.
In addition, this also solves the 'split-brained'-ness of having two
paths, which has endlessly confused people in the past.
I'm sad to see these sections go, but I think it's for the best.
Fixes #30471
Fixes #30163
Fixes #30162
Fixes #25488
Fixes #30345
Fixes #29590
Fixes #28713
Fixes #28915
And probably others. This lengthy list alone is enough to show that
these should have been removed.
RIP.
|
