| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This pull request tries to fix #19340, which states two ICE cases related to enum struct variants.
It is my first attempt to fix the compiler. I found this solution by trial and error, so the method used to fix the issue looks very hacky. Please review it, and direct me to find a better solution.
I'm also to add test cases. Where should I put them? Maybe `src/test/run-pass/issue-19340.rs`?
|
|
Fixes the second case of #19340.
|
|
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
|
|
|
|
No semantic changes, no enabling `if let` where it wasn't already enabled.
|
|
|
|
Sister pull request of https://github.com/rust-lang/rust/pull/19288, but
for the other style of block doc comment.
|
|
|
|
- Add `IntoCow` trait, and put it in the prelude
- Add `is_owned`/`is_borrowed` methods to `Cow`
- Add `CowString`/`CowVec` type aliases (to `Cow<'_, String, str>`/`Cow<'_, Vec, [T]>` respectively)
- `Cow` implements: `Show`, `Hash`, `[Partial]{Eq,Ord}`
- `impl BorrowFrom<Cow<'a, T, B>> for B`
[breaking-change]s:
- `IntoMaybeOwned` has been removed from the prelude
- libcollections: `SendStr` is now an alias to `CowString<'static>` (it was aliased to `MaybeOwned<'static>`)
- libgraphviz:
- `LabelText` variants now wrap `CowString` instead of `MaybeOwned`
- `Nodes` and `Edges` are now type aliases to `CowVec` (they were aliased to `MaybeOwnedVec`)
- libstd/path: `Display::as_maybe_owned` has been renamed to `Display::as_cow` and now returns a `CowString`
- These functions now accept/return `Cow` instead of `MaybeOwned[Vector]`:
- libregex: `Replacer::reg_replace`
- libcollections: `str::from_utf8_lossy`
- libgraphviz: `Id::new`, `Id::name`, `LabelText::pre_escaped_content`
- libstd: `TaskBuilder::named`
r? @aturon
|
|
|
|
Includes differentiation between assigned_fragments and
moved_fragments, support for all-but-one array fragments, and
instrumentation to print out the moved/assigned/unmmoved/parents for
each function, factored out into separate submodule.
|
|
|
|
This is accomplished by:
1. Add `MatchMode` enum to `expr_use_visitor`.
2. Computing the match mode for each pattern via a pre-pass, and then
passing the mode along when visiting the pattern in
expr_use_visitor.
3. Adding a `fn matched_pat` callback to expr_use_visitor, which is
called on interior struct and enum nodes of the pattern (as opposed
to `fn consume_pat`, which is only invoked for identifiers at the
leaves of the pattern), and invoking it accordingly.
Of particular interest are the `cat_downcast` instances established
when matching enum variants.
|
|
|
|
To make this clean, refactored old `LoanPath` enum into a
`LoanPath` struct with a `ty::t` and a newly-added `LoanPathVariant` enum.
This enabled me to get rid of the ugly and fragile `LoanPath::to_type`
method, and I can probably also get rid of other stuff that was
supporting it, maybe.
|
|
`LpDowncast` carries the `DefId` of the variant itself. To support
this, added the enum variant `DefId` to the `cat_downcast` variant in
`mem_categorization::categorization`.
(updated to fix mem_categorization to handle downcast of enum
struct-variants properly.)
|
|
r=nikomatsakis
(Previously, scopes were solely identified with NodeId's; this
refactoring prepares for a future where that does not hold.)
Ground work for a proper fix to #8861.
|
|
(Previously, statically identifiable scopes/regions were solely
identified with NodeId's; this refactoring prepares for a future
where that 1:1 correspondence does not hold.)
|
|
r=acrichto
Use the expected type to infer the argument/return types of unboxed closures. Also, in `||` expressions, use the expected type to decide if the result should be a boxed or unboxed closure (and if an unboxed closure, what kind).
This supercedes PR #19089, which was already reviewed by @pcwalton.
|
|
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:
* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
Signed, and Float. It is recommended to instead use Show wherever possible or
to use adaptor structs to implement other methods of formatting.
* The format specifier for Boolean has changed from `t` to `b`.
* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
struct instead of an enum. The `WriteError` variant no longer exists.
* The `format_args_method!` macro has been removed with no replacement. Alter
code to use the `format_args!` macro instead.
* The public fields of a `Formatter` have become read-only with no replacement.
Use a new formatting string to alter the formatting flags in combination with
the `write!` macro. The fields can be accessed through accessor methods on the
`Formatter` structure.
Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]
Closes #18904
|
|
optional unboxed closure kind.
|
|
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:
* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
Signed, and Float. It is recommended to instead use Show wherever possible or
to use adaptor structs to implement other methods of formatting.
* The format specifier for Boolean has changed from `t` to `b`.
* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
struct instead of an enum. The `WriteError` variant no longer exists.
* The `format_args_method!` macro has been removed with no replacement. Alter
code to use the `format_args!` macro instead.
* The public fields of a `Formatter` have become read-only with no replacement.
Use a new formatting string to alter the formatting flags in combination with
the `write!` macro. The fields can be accessed through accessor methods on the
`Formatter` structure.
Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]
Closes #18904
|
|
|
|
|
|
|
|
|
|
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
|
|
|
|
This should improve performance
|
|
|
|
Drill down the loan path for McDeclared references as well since
it might lead to an upvar. Closes #18769
|
|
|
|
Closes #18126.
|
|
Conflicts:
src/libcollections/vec.rs
|
|
Conflicts:
src/libcollections/slice.rs
src/libcore/failure.rs
src/libsyntax/parse/token.rs
src/test/debuginfo/basic-types-mut-globals.rs
src/test/debuginfo/simple-struct.rs
src/test/debuginfo/trait-pointers.rs
|
|
This commit enables implementations of IndexMut for a number of collections,
including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same
time this deprecates the `get_mut` methods on vectors in favor of using the
indexing notation.
cc #18424
|
|
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
|
|
|
|
|
|
it seems to be some kind of leftover GC-related detritus
|
|
it seems to be some kind of GC-related mess
|
|
|
|
Closes #18336
|
|
declared in the trait, not in the impl. In some cases that results in tighter rules, and in some cases looser. Correct for that.
|
|
Spring cleaning is here! In the Fall! This commit removes quite a large amount
of deprecated functionality from the standard libraries. I tried to ensure that
only old deprecated functionality was removed.
This is removing lots and lots of deprecated features, so this is a breaking
change. Please consult the deprecation messages of the deleted code to see how
to migrate code forward if it still needs migration.
[breaking-change]
|
|
This adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.
They look like this:
```
match.rs:10:13: 10:14 error: unreachable pattern [E0001]
match.rs:10 1 => {},
^
match.rs:3:1: 3:38 note: in expansion of foo!
match.rs:7:5: 20:2 note: expansion site
match.rs:10:13: 10:14 help: pass `--explain E0001` to see a detailed explanation
```
(`help` is coloured cyan.) Adding these errors on a separate line stops the lines from being too long, as discussed in #16619.
|
|
- Unify the representations of `cat_upvar` and `cat_copied_upvar`
- In `link_reborrowed_region`, account for the ability of upvars to
change their mutability due to later processing. A map of recursive
region links we may want to establish in the future is maintained,
with the links being established when the kind of the borrow is
adjusted.
- When categorizing upvars, add an explicit deref that represents the
closure environment pointer for closures that do not take the
environment by value. The region for the implicit pointer is an
anonymous free region type introduced for this purpose. This
creates the necessary constraint to prevent unsound reborrows from
the environment.
- Add a note to categorizations to make it easier to tell when extra
dereferences have been inserted by an upvar without having to
perform deep pattern matching.
- Adjust borrowck to deal with the changes. Where `cat_upvar` and
`cat_copied_upvar` were previously treated differently, they are
now both treated roughly like local variables within the closure
body, as the explicit derefs now ensure proper behavior. However,
error diagnostics had to be changed to explicitly look through the
extra dereferences to avoid producing confusing messages about
references not present in the source code.
Closes issue #17403. Remaining work:
- The error diagnostics that result from failed region inference are
pretty inscrutible and should be improved.
Code like the following is now rejected:
let mut x = 0u;
let f = || &mut x;
let y = f();
let z = f(); // multiple mutable references to the same location
This also breaks code that uses a similar construction even if it does
not go on to violate aliasability semantics. Such code will need to
be reworked in some way, such as by using a capture-by-value closure
type.
[breaking-change]
|
|
|
|
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
[rfc]: https://github.com/rust-lang/rfcs/pull/246
|
