| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Several Minor API / Reference Documentation Fixes
- Fix a few small errors in the reference.
- Fix paper cuts in the API docs.
Fixes #24882
Fixes #25233
Fixes #25250
|
|
|
|
|
|
|
|
The reference was claiming all vectors all bounds-checked at run-time, when constant vectors are usually checked at compile-time.
For the changed example see http://is.gd/28ak9E
|
|
|
|
|
|
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
|
|
This syntax was removed in b24a3b8 but references remained in the
grammar, the reference, rustdoc generation, and some auxiliary test
files that don't seem to have been used since 812637e.
|
|
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
|
|
Unsafe destructors were removed, added remarks about needed feature gates.
cc #16676
r? @steveklabnik
|
|
|
|
|
|
Fixes #24730
r? @alexcrichton
|
|
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! :fallen_leaf: :ocean:
|
|
Fixes #24730
|
|
I'm interested in helping out with #16676 but more in the grammar than the reference-- here's my first chunk, more to come!! :tada:
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
|
|
|
|
r? @steveklabnik
|
|
Also, remove the other brackets, because they make the whole sentence look awkward.
|
|
Reword so that the references to things above/below are up to date and a
bit more specific.
|
|
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.
|
|
|
|
Also, remove the other brackets, because they make the whole sentence
look awkward.
|
|
|
|
|
|
Clarify type inference of floating-point literals
|
|
Remove the name "multi-line string literal" since the rule appears to affect each line-break individually rather than the whole string literal. Re-word, and remove the stray reference to raw strings.
|
|
|
|
Transplant the grammar-related changes to grammar.md,
and remove all grammar talk from reference.md
|
|
Mention `non_ascii_idents` feature gate and remove unused productions.
r? @steveklabnik
|
|
The reference has broken links. This should fix it.
|
|
Mention non_ascii_idents feature gate and remove unused productions
|
|
|
|
The description of the syntax for single byte literals is missing the preceding `b` distinction.
|
|
|
|
Update 7.2.20 (`for` expressions):
* `for` loops now use `IntoIterator` instead of just `Iterator`
* Simplify the example by removing unnecessary `Vec::iter` call.
...and a fix for a minor formatting error.
r? @steveklabnik
|
|
Changed in #22838.
audited (raw) byte string literals @ #16676
|
|
|
|
|
|
* `for` loops now use `IntoIterator` instead of just `Iterator`
* Simplify the example by removing unnecessary `Vec::iter` call.
|
|
|
|
Audit & Edit Chapter 8.1 Types in reference manual
- Remove mention of unit type
- Update closure types and reference types sections
- Fix minor typos
|
|
- Remove mention of unit type
- Update closure types and reference types sections
- Fix minor typos
|
|
It was in pretty good shape, but since that is my pet peeve, I clarified the compiler/interpreter distinction and why it is irrelevant for this section. Otherwise only a couple of minor clarifications, and weasel words where reality is more complicated than the text accounted for (e.g., there is more than one kind of library).
r? @steveklabnik
|
|
`us` and `is` were replaced with `usize` and `isize` some time ago. Other than that, 3.5.2.1.5 is correct.
|
|
Changed in #22838.
audited (raw) byte string literals @ #16676
|
|
|
|
|
|
Add section for range expressions.
|
