- 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.
