- `File::open` is for opening a file in read-only mode
- `File::create` is for opening a file in write-only mode, which is what we want instead for this example to make sense
- I found n error in the book, before contributing the patch to fix it, I had to find where they were hosted
- It took me quite look to find where within the rust-lang *organisation* it was! ... and this should make it easier for the next person in the same position
- `FIle::open` is for opening a file in read-only mode
- `FIle::create` is for opening a file in write-only mode, which is what we want instead for this example to make sense
- I found n error in the book, before contributing the patch to fix it, I had to find where they were hosted
- It took me quite look to find where within the rust-lang *organisation* it was!
Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (#13547, #8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)).
One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! 🍂🌊
I'm interested in helping out with #16676 but more in the grammar than the reference-- here's my first chunk, more to come!! 🎉
I did pull a bit *out* of the reference, though, that was more relevant to the grammar but wasn't moved over as part of #24729.
I'm looking at, e.g. https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs, as the source of truth, please let me know if I should be checking against something else instead/in addition.
r? @steveklabnik
Since #24783, the style guidelines recommend that unit tests should live in a submodule `tests` rather than `test` to not clash with the possible use of libtest. This is especially important for benchmark tests as they require libtest. Fixes#24923.
Since #24783, the style guidelines recommend that unit tests should live in a submodule `tests` rather than `test` to not clash with the possible use of libtest. This is especially important for benchmark tests as they require libtest. Fixes#24923.
Closes#17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
