This adds support for lint groups to the compiler. Lint groups are a way of
grouping a number of lints together under one name. For example, this also
defines a default lint for naming conventions, named `bad_style`. Writing
`#[allow(bad_style)]` is equivalent to writing
`#[allow(non_camel_case_types, non_snake_case, non_uppercase_statics)]`. These
lint groups can also be defined as a compiler plugin using the new
`Registry::register_lint_group` method.
This also adds two built-in lint groups, `bad_style` and `unused`. The contents
of these groups can be seen by running `rustc -W help`.
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
The inference scheme proposed in <http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-experimental-new-type-inference-scheme-for-rust/>.
This is theoretically a [breaking-change]. It is possible that you may encounter type checking errors, particularly related to closures or functions with higher-ranked lifetimes or object types. Adding more explicit type annotations should help the problem. However, I have not been able to make an example that *actually* successfully compiles with the older scheme and fails with the newer scheme.
f? @pcwalton, @pnkfelix
Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.
Fixes issue #11943
This squashes the
> `for` loop expression has type `[type error]` which does not implement
> the `Iterator` trait
message that one received when writing `for ... in x` where was
previously found to have a type error.
Fixes#16042.
Per API meeting
https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md
# Changes to `core::option`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator` impl.
# Changes to `core::result`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator` impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants.
Due to deprecations, this is a:
[breaking-change]
For review. Not sure about the link_attrs stuff. Will work on converting all the tests.
extern crate "foobar" as foo;
extern crate foobar as foo;
Implements remaining part of RFC #47.
Addresses issue #16461.
Removed link_attrs from rust.md, they don't appear to be supported by
the parser.
DST coercions and DST fields in structs
The commits are not quite stand alone, I should probably squash them together before landing. In particular if you review the individual commits, then you'll see some scrappy stuff that gets fixed in later commits. But reading the commits in order might be easier to get an overall idea of what is going on.
The first commit includes putting back time zone into our time library - @pcwalton removed that as part of his de-~str'ing, but I had already converted it to use StrBuf, so we may as well leave it in. Update: no longer, this is removed in a later commit.
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
The privacy pass of the compiler was previously not taking into account the
privacy of foreign items, or bindings to external functions. This commit fixes
this oversight by encoding the visibility of foreign items into the metadata for
each crate.
Any code relying on this will start to fail to compile and the bindings must be
marked with `pub` to indicate that they can be used externally.
Closes#16725
[breaking-change]
This commits takes a similar strategy to the previous commit to implement
close_accept and clone for the native win32 pipes implementation.
Closes#15595
This commits implements {Tcp,Unix}Acceptor::{clone,close_accept} methods for
unix. A windows implementation is coming in a later commit.
The clone implementation is based on atomic reference counting (as with all
other clones), and the close_accept implementation is based on selecting on a
self-pipe which signals that a close has been seen.
Current version of rust fails when casting from bool, e.g.
```rust
fn main() {
let _a = false as uint;
let _b = true as uint;
let _c: [bool, ..false as uint];
let _d: [bool, ..true as uint];
// _a and _b work, but _c and _d result in an error
// error: expected constant expr for vector length: can't cast str to uint
}
```
This commit makes it work as expected.
Implements remaining part of RFC #47.
Addresses issue #16461.
Removed link_attrs from rust.md, they don't appear to be supported by
the parser.
Changed all the tests to use the new extern crate syntax
Change pretty printer to use 'as' syntax
int/uint aren't considered FFI safe, replace them with the actual type they
represent (i64/u64 or i32/u32). This is a breaking change, but at most a cast
to `uint` or `int` needs to be added.
[breaking-change]
As of RFC 18, struct layout is undefined. Opting into a C-compatible struct
layout is now down with #[repr(C)]. For consistency, specifying a packed
layout is now also down with #[repr(packed)]. Both can be specified.
To fix errors caused by this, just add #[repr(C)] to the structs, and change
#[packed] to #[repr(packed)]
Closes#14309
[breaking-change]
It's unfortunate that the read+write operands need special treatment in the AST. A separate vec for all expressions is an alternative, but it doesn't play nicely with trans.
Fixes#14936
Stop read+write expressions from expanding into two occurences
in the AST. Add a bool to indicate whether an operand in output
position if read+write or not.
Fixes#14936
First commit enables regex test on Windows. It was not working at some point (#13725), but it works now.
Second commit removes various FIXMEs regarding #13793, since upstream bug has been fixed.
declared with the same name in the same scope.
This breaks several common patterns. First are unused imports:
use foo::bar;
use baz::bar;
Change this code to the following:
use baz::bar;
Second, this patch breaks globs that import names that are shadowed by
subsequent imports. For example:
use foo::*; // including `bar`
use baz::bar;
Change this code to remove the glob:
use foo::{boo, quux};
use baz::bar;
Or qualify all uses of `bar`:
use foo::{boo, quux};
use baz;
... baz::bar ...
Finally, this patch breaks code that, at top level, explicitly imports
`std` and doesn't disable the prelude.
extern crate std;
Because the prelude imports `std` implicitly, there is no need to
explicitly import it; just remove such directives.
The old behavior can be opted into via the `import_shadowing` feature
gate. Use of this feature gate is discouraged.
This implements RFC #116.
Closes#16464.
[breaking-change]
Crates that are resolved normally have their path canonicalized and all
symlinks resolved. This does currently not happen for paths specified
using the --extern option to rustc, which can lead to rustc thinking
that it encountered two different versions of a crate, when it's
actually the same version found through different paths.
Fixes#16496
When a struct implements Drop, its fields should still drop in
declaration order (just as they do when the struct does not implement
Drop).
Fixes#16492.
When a struct implements Drop, its fields should still drop in
declaration order (just as they do when the struct does not implement
Drop).
Fixes#16492.
Crates that are resolved normally have their path canonicalized and all
symlinks resolved. This does currently not happen for paths specified
using the --extern option to rustc, which can lead to rustc thinking
that it encountered two different versions of a crate, when it's
actually the same version found through different paths.
To fix this, we must store the canonical path for crates found via
--extern and also use the canonical path when comparing paths.
Fixes#16496
These `where` clauses are accepted everywhere generics are currently
accepted and desugar during type collection to the type parameter bounds
we have today.
A new keyword, `where`, has been added. Therefore, this is a breaking
change. Change uses of `where` to other identifiers.
[breaking-change]
r? @nikomatsakis (or whoever)
These `where` clauses are accepted everywhere generics are currently
accepted and desugar during type collection to the type parameter bounds
we have today.
A new keyword, `where`, has been added. Therefore, this is a breaking
change. Change uses of `where` to other identifiers.
[breaking-change]
This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.
This breaks code that looked like:
let mut f;
{
let x = &5i;
f = |&mut:| *x + 10;
}
Change this code to avoid having a reference escape. For example:
{
let x = &5i;
let mut f; // <-- move here to avoid dangling reference
f = |&mut:| *x + 10;
}
I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.
Closes#14449.
[breaking-change]
r? @pnkfelix
This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.
This breaks code that looked like:
let mut f;
{
let x = &5i;
f = |&mut:| *x + 10;
}
Change this code to avoid having a reference escape. For example:
{
let x = &5i;
let mut f; // <-- move here to avoid dangling reference
f = |&mut:| *x + 10;
}
I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.
Closes#14449.
[breaking-change]
by-reference upvars.
This partially implements RFC 38. A snapshot will be needed to turn this
on, because stage0 cannot yet parse the keyword.
Part of #12831.
r? @alexcrichton
by-reference upvars.
This partially implements RFC 38. A snapshot will be needed to turn this
on, because stage0 cannot yet parse the keyword.
Part of #12381.
I chose to make two of them because I wanted something close to an
"end-to-end" test (*), but at the same time I wanted a test that
would run on Windows (**).
(*) The run-make test serves as the end-to-end: It constructs an input
that is trying to subvert the hack and we are going to check that it
fails in the attempt).
(**) The compile-fail-fulldeps test serves as a more narrow test that
will be tested on all platforms. It also attempts to subvert the
hack, testing that when you use `new_parser_from_tts`, the resulting
parser does not support reading embedded Idents.
This fixes borrow checking for closures. Code like this will break:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
let p = &this.x;
&mut this.x;
};
r()
}
Change this code to not take multiple mutable references to the same value. For
example:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
&mut this.x;
};
r()
}
Closes#16361.
[breaking-change]
r? @nikomatsakis
`for` loop heads.
This breaks code like:
let x = Some(box 1i);
for &a in x.iter() {
}
Change this code to obey the borrow checking rules. For example:
let x = Some(box 1i);
for &ref a in x.iter() {
}
Closes#16205.
[breaking-change]
r? @nikomatsakis
`for` loop heads.
This breaks code like:
let x = Some(box 1i);
for &a in x.iter() {
}
Change this code to obey the borrow checking rules. For example:
let x = Some(box 1i);
for &ref a in x.iter() {
}
Closes#16205.
[breaking-change]
Previously the stability lint considered cross-crate items only. That's appropriate for unstable and experimental levels, but not for deprecation.
In addition to changing the lint, this PR takes care of the fallout: a number of deprecated items that were being used throughout libstd.
Closes#16409
Due to deny(deprecated), this is a:
[breaking-change]
This fixes borrow checking for closures. Code like this will break:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
let p = &this.x;
&mut this.x;
};
r()
}
Change this code to not take multiple mutable references to the same value. For
example:
struct Foo {
x: int,
}
pub fn main() {
let mut this = &mut Foo {
x: 1,
};
let r = || {
&mut this.x;
};
r()
}
Closes#16361.
[breaking-change]
Previously the lint considered cross-crate items only. That's
appropriate for unstable and experimental levels, but not for
deprecation.
Closes#16409
Due to deny(deprecation), this is a:
[breaking-change]
There was a bug in both libnative and libuv which prevented child processes from
being spawned correctly on windows when one of the arguments was an empty
string. The libuv bug has since been fixed upstream, and the libnative bug was
fixed as part of this commit.
When updating libuv, this also includes a fix for #15149.
Closes#15149Closes#16272
The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
This generalises the behaviour with struct fields (which recieve no
dead_code warning if they have a leading _), and other similar lints, to
all items, e.g. `fn _foo() {} fn main() {}` has no warnings.
Extended `ast_map::Map` with an iterator over all node id's that match a path suffix.
Extended pretty printer to let users choose particular items to pretty print, either by indicating an integer node-id, or by providing a path suffix.
* Example 1: the suffix `typeck::check::check_struct` matches the item with the path `rustc::middle::typeck::check::check_struct` when compiling the `rustc` crate.
* Example 2: the suffix `and` matches `core::option::Option::and` and `core::result::Result::and` when compiling the `core` crate.
Refactored `pprust` slightly to support the pretty printer changes.
(See individual commits for more description.)
This requires avoiding `quote_...!` for constructing the parts of the
__test module, since that stringifies and reinterns the idents, losing
the special gensym'd nature of them. (#15962.)
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This requires avoiding `quote_...!` for constructing the parts of the
__test module, since that stringifies and reinterns the idents, losing
the special gensym'd nature of them. (#15962.)
meaning `'b outlives 'a`. Syntax currently does nothing but is needed for full
fix to #5763. To use this syntax, the issue_5763_bootstrap feature guard is
required.
This commit stabilizes the `std::sync::atomics` module, renaming it to
`std::sync::atomic` to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.
The vast majority of the module is now `stable`. However, the
`AtomicOption` type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.
Due to deprecations, this is a:
[breaking-change]
Generic extern functions written in Rust have their names mangled, as well as their internal clownshoe __rust_abi functions. This allows e.g. specific monomorphizations of these functions to be used as callbacks.
Closes#12502.
There was a bug in both libnative and libuv which prevented child processes from
being spawned correctly on windows when one of the arguments was an empty
string. The libuv bug has since been fixed upstream, and the libnative bug was
fixed as part of this commit.
When updating libuv, this also includes a fix for #15149.
Closes#15149Closes#16272
This ended up passing through the lexer but dying later on in parsing when it
wasn't handled. The strategy taken was to copy the `str_lit` funciton, but adapt
it for bytes.
Closes#16278
Fixes missing overflow lint for i64 #14269
The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for
overflows.
We can't lint in the parse phase, so we emit a compiler error, as we do for overflowing `u64`
Perhaps a consistent behaviour would be to emit a parse error for *all* overflowing integer types.
See #14269
The `type_overflow` lint, doesn't catch the overflow for `i64` because
the overflow happens earlier in the parse phase when the `u64` as biggest
possible int gets casted to `i64` , without checking the for overflows.
We can't lint in the parse phase, so a refactoring of the `LitInt` type
was necessary.
The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one
type `LitInt` which stores it's value as `u64`. An additional parameter was
added which indicate the signedness of the type and the sign of the value.
This commit stabilizes the `std::sync::atomics` module, renaming it to
`std::sync::atomic` to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.
The vast majority of the module is now `stable`. However, the
`AtomicOption` type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.
Due to deprecations, this is a:
[breaking-change]
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not
actually guaranteed to link the library at all. The reason for this is that if
the external library doesn't have any referenced symbols in the object generated
by rustc, the entire library is dropped by the linker.
For dynamic native libraries, this is solved by passing -lfoo for all downstream
compilations unconditionally. For static libraries in rlibs this is solved
because the entire archive is bundled in the rlib. The only situation in which
this was a problem was when a static native library was linked to a rust dynamic
library.
This commit brings the behavior of dylibs in line with rlibs by passing the
--whole-archive flag to the linker when linking native libraries. On OSX, this
uses the -force_load flag. This flag ensures that the entire archive is
considered candidate for being linked into the final dynamic library.
This is a breaking change because if any static library is included twice in the
same compilation unit then the linker will start emitting errors about duplicate
definitions now. The fix for this would involve only statically linking to a
library once.
Closes#15460
[breaking-change]
Using the Show impl for Names created global symbols with names like
`"str\"str\"(1027)"`. This adjusts strings, binaries and vtables to
avoid using that impl.
Fixes#15799.
This is an alternative to upgrading the way rvalues are handled in the
borrow check. Making rvalues handled more like lvalues in the borrow
check caused numerous problems related to double mutable borrows and
rvalue scopes. Rather than come up with more borrow check rules to try
to solve these problems, I decided to just forbid pattern bindings after
`@`. This affected fewer than 10 lines of code in the compiler and
libraries.
This breaks code like:
match x {
y @ z => { ... }
}
match a {
b @ Some(c) => { ... }
}
Change this code to use nested `match` or `let` expressions. For
example:
match x {
y => {
let z = y;
...
}
}
match a {
Some(c) => {
let b = Some(c);
...
}
}
Closes#14587.
[breaking-change]
Closes#16097 (fix variable name in tutorial)
Closes#16100 (More defailbloating)
Closes#16104 (Fix deprecation commment on `core::cmp::lexical_ordering`)
Closes#16105 (fix formatting in pointer guide table)
Closes#16107 (remove serialize::ebml, add librbml)
Closes#16108 (Fix heading levels in pointer guide)
Closes#16109 (rustrt: Don't conditionally init the at_exit QUEUE)
Closes#16111 (hexfloat: Deprecate to move out of the repo)
Closes#16113 (Add examples for GenericPath methods.)
Closes#16115 (Byte literals!)
Closes#16116 (Add a non-regression test for issue #8372)
Closes#16120 (Deprecate semver)
Closes#16124 (Deprecate uuid)
Closes#16126 (Deprecate fourcc)
Closes#16127 (Remove incorrect example)
Closes#16129 (Add note about production deployments.)
Closes#16131 (librustc: Don't ICE when trying to subst regions in destructor call.)
Closes#16133 (librustc: Don't ICE with struct exprs where the name is not a valid struct.)
Closes#16136 (Implement slice::Vector for Option<T> and CVec<T>)
Closes#16137 (alloc, arena, test, url, uuid: Elide lifetimes.)
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
Our implementation of ebml has diverged from the standard in order
to better serve the needs of the compiler, so it doesn't make much
sense to call what we have ebml anyore. Furthermore, our implementation
is pretty crufty, and should eventually be rewritten into a format
that better suits the needs of the compiler. This patch factors out
serialize::ebml into librbml, otherwise known as the Really Bad
Markup Language. This is a stopgap library that shouldn't be used
by end users, and will eventually be replaced by something better.
[breaking-change]
Currently, each time a function is monomorphized, all items within that function are translated. This is unnecessary work because the inner items already get translated when the function declaration is visited by `trans_item`. This patch adds a flag to the `FunctionContext` to prevent translation of items during monomorphization.
Remove the ability of the borrow checker to determine that repeated
dereferences of a Box<T> refer to the same memory object. This will
usually require one of two workarounds:
1) The interior of a Box<T> will sometimes need to be moved / borrowed
into a temporary before moving / borrowing individual derived paths.
2) A `ref x` pattern will have to be replaced with a `box ref x`
pattern.
Fixes#16094.
[breaking-change]
Like with libnative, when a green task failed to spawn it would leave the world
in a corrupt state where the local scheduler had been dropped as well as the
local task. Also like libnative, this patch sets up a "bomb" which when it goes
off will restore the state of the world.
This adds support for `quote_arm!(cx, $pat => $expr)`, and `macro_rules!(($a:arm) => (...))`. It also fixes a bug in pretty printing, where this would generate invalid code:
```
match { 5i } {
1 => 2,
_ => 3,
}
```
It would generate this code:
```
match { 5i } {
1 => 2
_ => 3
}
```
Finally, it adds a couple helper methods to `ExtCtxt`.
When dealing with HTTP request or responses, many tokens are case-insensitive in the ASCII range but the bytes from the network are not necessarily valid UTF-8.
**[breaking-change]** Rather than adding new very similar traits, this re-uses the `std::ascii::OwnedStrAsciiExt` and `std::ascii::StrAsciiExt` traits, but rename to remove `Str` since that does not apply for bytes.
This PR also makes `std::ascii::ASCII_UPPER_MAP` and `std::ascii::ASCII_LOWER_MAP`, the lookup table all these methods are based on, public. In case there is something else related to ASCII case we haven’t thought of yet, that can be implemented outside of libstd without duplicating the tables.
Although this is a breaking change, I thought this could do without an RFC since the relevant traits are not in the prelude.
r? @alexcrichton
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)
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
Everyone agreed except @thestinger. As @thestinger contribution on this file is trivial,
we can relicense it.
Related to #14248, close#15330
@brson OK?
This commit applies stability attributes to the contents of these modules,
summarized here:
* The `unit` and `bool` modules have become #[unstable] as they are purely meant
for documentation purposes and are candidates for removal.
* The `ty` module has been deprecated, and the inner `Unsafe` type has been
renamed to `UnsafeCell` and moved to the `cell` module. The `marker1` field
has been removed as the compiler now always infers `UnsafeCell` to be
invariant. The `new` method i stable, but the `value` field, `get` and
`unwrap` methods are all unstable.
* The `tuple` module has its name as stable, the naming of the `TupleN` traits
as stable while the methods are all #[unstable]. The other impls in the module
have appropriate stability for the corresponding trait.
* The `arc` module has received the exact same treatment as the `rc` module
previously did.
* The `any` module has its name as stable. The `Any` trait is also stable, with
a new private supertrait which now contains the `get_type_id` method. This is
to make the method a private implementation detail rather than a public-facing
detail.
The two extension traits in the module are marked #[unstable] as they will not
be necessary with DST. The `is` method is #[stable], the as_{mut,ref} methods
have been renamed to downcast_{mut,ref} and are #[unstable].
The extension trait `BoxAny` has been clarified as to why it is unstable as it
will not be necessary with DST.
This is a breaking change because the `marker1` field was removed from the
`UnsafeCell` type. To deal with this change, you can simply delete the field and
only specify the value of the `data` field in static initializers.
[breaking-change]
Rename and gensym the runtime on import, so that users
can't refer to the `native` crate.
This is unlikely to break code, but users should import the "native" crate directly.
[breaking-change]
cc @alexcrichton
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]
method calls are involved.
This breaks code like:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = box 3i; // note no `Copy` bound
take_param(&x);
}
Change this code to not contain a type error. For example:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = 3i; // satisfies `Copy` bound
take_param(&x);
}
Closes#15860.
[breaking-change]
r? @alexcrichton
method calls are involved.
This breaks code like:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = box 3i; // note no `Copy` bound
take_param(&x);
}
Change this code to not contain a type error. For example:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = 3i; // satisfies `Copy` bound
take_param(&x);
}
Closes#15860.
[breaking-change]
librustc: Stop desugaring `for` expressions and translate them directly.
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes#15392.
[breaking-change]
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes#15392.
[breaking-change]
This is done entirely in the libraries for functions up to 16 arguments.
A macro is used so that more arguments can be easily added if we need.
Note that I had to adjust the overloaded call algorithm to not try
calling the overloaded call operator if the callee is a built-in
function type, to prevent loops.
Closes#15448.
