Closes#15296 (Update disclaimer to improve clarity and intent)
Closes#15804 (Don't ICE when dealing with the count expr for fixed array types in various places.)
Closes#15893 (lint: Improve ffi-unsafe enum lint warning)
Closes#16045 (Rename Integer divides to is_multiple_of.)
Closes#16055 (manual: update list of feature gates, add phase attribute)
Closes#16056 (Improve documentation of rounding functions)
Closes#16061 (Remove references to non-existant functions in the std::path documentation)
Closes#16062 (Fix documentation error in MutableVectorAllocating::move_from)
Closes#16063 (adding discuss.rust-lang to community)
Closes#16064 (rustc: Switch dsymutil status => output)
Closes#16066 (making raw source display better)
Closes#16079 (doc: add missing word)
Closes#16080 (Update LLVM to fix miscompilations due to wrongfully removed lifetime intrinsics)
Closes#16084 (Elide lifetimes around Arc<T>.)
Closes#16085 (Gedit/gtksourceview language spec: add raw strings)
Closes#16086 (Implement Hash for DList)
… and color (raw) strings as such in attributes.
This fixes cases where a string contains ] inside an attribute:
that ] used to incorrectly end the attribute coloring.
For large (many lines) doc comments, I’ve found preferable to use
`#![doc = r#"..."#]` to avoid prefixing every line with `//!`.
* Make the code fill up the full width of the page (no massive whitespace on the left)
* Move the code down to make it not intersect the logo
* Set a min-width and remove the max-width so that the code doesn't scroll internally, but instead scrolls the page, meaning horizontal scroll bars are always available
* Set overflow to actually overflow, just to be sure
Fixes#15891
It is being changed because the previous wording was ambiguous.
`a.divides(b)` implied `a % b == 0` but it sounds like the other way
around. `9.divides(&3) == true` but we might read that as
"does 9 divide 3?". It has been renamed to sidestep the ambiguity.
Work around the change by using `is_multiple_of` instead.
[breaking-change]
I think this is an improvement of the previous warning message, which
- like the comment that I removed implies - is in need of some
improvement.
I've opted to point the user in the right direction w.r.t how to fix the
problem, which I think is good form.
Not being familiar with the repr(...) attribute, I personally had to
check the lint rules myself to figure out what was wrong. Hopefully,
this will save he next person some time and headache.
Signed-off-by: Anton Lofgren <alofgren@op5.com>
the CFG for match statements.
There were two bugs in issue #14684. One was simply that the borrow
check didn't know about the correct CFG for match statements: the
pattern must be a predecessor of the guard. This disallows the bad
behavior if there are bindings in the pattern. But it isn't enough to
prevent the memory safety problem, because of wildcards; thus, this
patch introduces a more restrictive rule, which disallows assignments
and mutable borrows inside guards outright.
I discussed this with Niko and we decided this was the best plan of
action.
This breaks code that performs mutable borrows in pattern guards. Most
commonly, the code looks like this:
impl Foo {
fn f(&mut self, ...) {}
fn g(&mut self, ...) {
match bar {
Baz if self.f(...) => { ... }
_ => { ... }
}
}
}
Change this code to not use a guard. For example:
impl Foo {
fn f(&mut self, ...) {}
fn g(&mut self, ...) {
match bar {
Baz => {
if self.f(...) {
...
} else {
...
}
}
_ => { ... }
}
}
}
Sometimes this can result in code duplication, but often it illustrates
a hidden memory safety problem.
Closes#14684.
[breaking-change]
r? @pnkfelix
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
Some of the fixes include:
- fixing mismatch between the documentation and the function parameters. (i.e. documentation references `path` parameter, but it's actually called `from`, or vice versa)
- A few Error sections were missing an "if" on the middle clause. For example, they used to be: "This function will return an error if [Thing], [Another Thing], or if [Yet Another Thing]." I added an "if" so it becomes "This function will return an error if [Thing], if [Another Thing], or if [Yet Another Thing]"
- The error sections previously started off with 3 different phrases:
- "This function will return an error if ..."
- "Will return an error if ..."
- "This call will return an error if ..."
I've standardized on the first phrase.
Prior to this, the code there had a few issues:
- Default implementations inconsistently either had the prefix `noop_` or
not.
- Some default methods where implemented in terms of a public noop function
for user code to call, others where implemented directly on the trait
and did not allow users of the trait to reuse the code.
- Some of the default implementations where private, and thus not reusable
for other implementors.
- There where some bugs where default implementations called other default
implementations directly, rather than to the underlying Folder, with the
result of some AST nodes never being visited even if the user implemented that
method. (For example, the current Folder never folded struct fields)
This commit solves this situation somewhat radically by making _all_
`fold_...` functions in the module into Folder methods, and implementing
them all in terms of public `noop_...` functions for other implementors to
call out to.
Some public functions had to be renamed to fit the new system, so this is a
breaking change.
[breaking-change]
We previously reexported entire modules, which caused private things to
become reachable and trip the dead code and private items in public API
lints.
Closes#15912
Previously the implementation of Hash was limited to tuples of up to arity 8. This increases it to tuples of up to arity 12.
Also, the implementation macro for `Hash` used to expand to something like this:
impl Hash for (a7,)
impl Hash for (a6, a7)
impl Hash for (a5, a6, a7)
...
This style is inconsistent with the implementations in core::tuple, which look like this:
impl Trait for (A,)
impl Trait for (A, B)
impl Trait for (A, B, C)
...
This is perhaps a minor point, but it does mean the documentation pages are inconsistent. Compare the tuple implementations in the documentation for [Hash](http://static.rust-lang.org/doc/master/std/hash/trait.Hash.html) and [PartialOrd](http://static.rust-lang.org/doc/master/core/cmp/trait.PartialOrd.html)
This changes the Hash implementation to be consistent with `core::tuple`.
