- Check privacy sanity in all blocks, not only function bodies
- Check all fields, not only named
- Check all impl items, not only methods
- Check default impls
- Move the sanity check in the beginning of privacy checking, so others could rely on it
Technically it's a [breaking-change], but I expect no breakage because, well, it's *sane* privacy visitor, if code is broken it must be insane by definition!
The struct_variant feature was accepted and is no longer feature gated.
See #19122, #19124
§6.1.6 Enumerations shows an example of a struct-like enum variant.
In src/doc/trpl/error-handling.md, in this section:
It mentions three steps, to "convert this to proper error handling", the last one being:
3. Handle the error in main.
However, it is not shown. This pull request adds a code example showing how `main`'s call to `search` should use case analysis. I am still very much new to learning Rust, so this may not be idiomatic. Happy to make changes with guidance.
The struct_variant feature was accepted and is no longer feature gated.
See #19122, #19124
§6.1.6 Enumerations shows an example of a struct-like enum variant.
Originally, this was my 30 minute introduction, and we eventually made
it the opener to the book. But as #25918 has shown, the example I use
here has some issues. The good news is that Rust makes heap allocation
syntatically expensive, but the bad news is that that means showing
equivalent programs from Rust and other languages is difficult. After
thinking about it, I'm not sure this section is pulling its weight, and
since it has problems, I'd rather just pull it than try to re-write it
right now. I think the book is fine without it.
FIxes#25918
Originally, this was my 30 minute introduction, and we eventually made
it the opener to the book. But as #25918 has shown, the example I use
here has some issues. The good news is that Rust makes heap allocation
syntatically expensive, but the bad news is that that means showing
equivalent programs from Rust and other languages is difficult. After
thinking about it, I'm not sure this section is pulling its weight, and
since it has problems, I'd rather just pull it than try to re-write it
right now. I think the book is fine without it.
FIxes#25918
Reword "Writing the logic" paragraph to prevent `unwrap` being confused for a macro (and other small changes to improve the flow of the paragraph).
cc @steveklabnik
I did some preliminary editing work with No Starch on the first chapter of the book, and here's some of the results. We're going to want to return to this later when @brson etc's new rustup work is done, so this is mostly just a first pass.
But, we agreed that having separate chapters for each of this bit of intro is a bit excessive. So let's move all of this intro stuff into one chapter.
I'd appreciate a careful review of this, as there was also some confusion about some things, which resulted in me taking one huge markdown file apart and splitting it back up, as well as some editor issues, so I _think_ this looks good, but double checking things matters!
/cc @aturon
I read this section a few times before even having a guess what
was meant, then consulted IRC for confirmation. It may be that I
was thick-headed, but I think this is a useful addition.
I read this section a few times before even having a guess what
was meant, then consulted IRC for confirmation. It may be that I
was thick-headed, but I think this is a useful addition.
Note: for now, this change only affects `-windows-gnu` builds.
So why was this `libgcc` dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process. The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process. All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process. This pretty much means that the unwinder must be in a shared library (unless everything is statically linked).
Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once. So if we link the unwinder statically to one of Rust's crates, everything should be fine.
Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them. So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`!
A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.
This is two sentences that have been comma spliced, and should
be split with a full stop. (This error made me stop and re-read,
and I submit this as an actual improvement to readability, not
as a grammar weird-o!)
This is two sentences that have been comma spliced, and should
be split with a full stop. (This error made me stop and re-read,
and I submit this as an actual improvement to readability, not
as a grammar weird-o!)
I put the reference under the function return operator `->` rather than near the suggested `!` operators as I thought it was more relevant there.
Resolves#29431
As displayed before this commit, I found the book confusing in its
explanation of `#`-led comments in `rust` blocks. Possibly the
biggest confusion was because the many-dashes construct does not
become an HR element in the Markdown translator used, so things were
not being properly set off.
This change should more clearly show the as-rendered content as
rendered, and the as-coded content as code.
I somehow missed a word behind the numbers while going through this section, don't know what the best approach would be though since "**available** addresses" sounds good to me, too".
As displayed before this commit, I found the book confusing in its
explanation of `#`-led comments in `rust` blocks. Possibly the
biggest confusion was because the many-dashes construct does not
become an HR element in the Markdown translator used, so things were
not being properly set off.
This change should more clearly show the as-rendered content as
rendered, and the as-coded content as code.
PR for #28157. At the moment, `rustc` emits a warning when a bare semicolon is encountered (could also be a fail, but I think this is a backwards incompatible change).
Also I am not sure where the best place for a test for that warning would be. Seems run-pass tests do not check warnings.
It's possible that there is some meaning I'm not grasping from the headers "Traits bounds for generic functions" and "Traits bounds for generic structs", but they seem to me like they could be clearer and more grammatically correct.
When reading this paragraph, the beginning Rust programmer is starting
to write a Hello World program. We have just told her to name the file
`main.rs`, and immediately afterward, a `hello_world.rs` is mentioned.
I changed this to an unrelated filename (incidentally one that appears
in this repository) to make it clear that this is just an example.
Also, wording it as a declarative sentence rather than an imperative one
further separates it from the Hello World instructions in this section.
r? @steveklabnik
(Let me know if I'm sending too many PRs -- I can batch up TRPL edits, say, per chapter, if that works better. Or I can just refrain from editing TRPL as I read through it, if these are not sufficiently useful.)
The paragraph here seemed confusing, so I reworded it. Also added
another possible reason why `curl | sh` might be objectionable to users.
r? @steveklabnik
This commit expands the "supported platforms" section of the book to include
documentation on the tiers that Rust currently has as well as organizing all
supported platforms into these various tiers. Infrastructure improvements over
the next few months are likely to change the location of may of these platforms
over, but for now this should faithfully represent what we've got today!
When reading this paragraph, the beginning Rust programmer is starting
to write a Hello World program. We have just told her to name the file
`main.rs`, and immediately afterward, a `hello_world.rs` is mentioned.
I changed this to an unrelated filename (incidentally one that appears
in this repository) to make it clear that this is just an example.
Also, wording it as a declarative sentence rather than an imperative one
further separates it from the Hello World instructions in this section.
This commit expands the "supported platforms" section of the book to include
documentation on the tiers that Rust currently has as well as organizing all
supported platforms into these various tiers. Infrastructure improvements over
the next few months are likely to change the location of may of these platforms
over, but for now this should faithfully represent what we've got today!
Yay, markdown isn't standardized and rustbook's parser has subtle incompatibilities with Github's! So in the Github preview you don't see that this list fails to separate from the previous paragraph. I think this should fix it, but I didn't check.
Remove leading newlines; replace lines containing only whitespace with empty lines; replace multiple trailing newlines with a single newline; remove trailing whitespace in lines.
This PR was created semiautomatically.
Remove leading newlines; replace lines containing only whitespace with empty lines; replace multiple trailing newlines with a single newline; remove trailing whitespace in lines
To augment the didactic effect, made placed the thread::sleep_ms call in the last example, so that there will be time for the other locks to happen; without this, I was unable to observe the deadlock in over 1,000 runs when there was no left-handed philosopher.
When going through the docs, it is not clear that binary files cannot be tested. Additionally, it is hard to find the proper structure of a Rust crate and it took me several hours of looking through the docs to find the crates and modules section. I think we can link to it from here and it will be beneficial to those who are coming to the language.
When going through the docs, it is not clear that binary files cannot be tested. Additionally, it is hard to find the proper structure of a Rust crate and it took me several hours of looking through the docs to find the crates and modules section. I think we can link to it from here and it will be beneficial to those who are coming to the language.
Regarding [#29063 _[Docs] Terminology inconsistency between 'iterator adapters' and 'iterator adaptors'_](https://github.com/rust-lang/rust/issues/29063) :
This PR replaces 'iterator adapters' appearances (in TRPL book) to 'iterator adaptors', thus embracing the terminology used along the API docs and achieving consistency between both sources.
Before this commit, the first "A Rust library" code sample produced
the following compilation warning:
```
test.rs:7:22: 7:36 warning: unnecessary parentheses around `for` head
expression, #[warn(unused_parens)] on by default
test.rs:7 for _ in (0..5_000_000) {
```
This commit just removes the parens around the range 0..5_000_000 thereby removing the compilation warning.
Regarding #29063: Replace 'iterator adapters' appearances to
'iterator adaptors', thus embracing the terminology used along the
API docs and achieving consistency between both sources.
Before this commit, the first "A Rust library" code sample produced
the following compilation warning:
```
test.rs:7:22: 7:36 warning: unnecessary parentheses around `for` head
expression, #[warn(unused_parens)] on by default
test.rs:7 for _ in (0..5_000_000) {
```
This commit just removes the parens around the range 0..5_000_000.
This patch uses the same data structures for structs and enum variants in AST and HIR. These changes in data structures lead to noticeable simplification in most of code dealing with them.
I didn't touch the top level, i.e. `ItemStruct` is still `ItemStruct` and not `ItemEnum` with one variant, like in the type checker.
As part of this patch, structures and variants get the `kind` field making distinction between "normal" structs, tuple structs and unit structs explicit instead of relying on the number of fields and presence of constructor `NodeId`. In particular, we can now distinguish empty tuple structs from unit structs, which was impossible before! Comprehensive tests for empty structs are added and some improvements to empty struct feature gates are made. Some tests don't pass due to issue https://github.com/rust-lang/rust/issues/28692 , they are still there for completeness, but are commented out.
This patch fixes issue mentioned in https://github.com/rust-lang/rust/issues/16819#issuecomment-139509861, now emptiness of tuple structs is checked after expansion.
It also touches https://github.com/rust-lang/rust/issues/28750 by providing span for visit_struct_def
cc https://github.com/rust-lang/rust/pull/28336
r? @nrc
