- 25 2月, 2015 2 次提交
-
-
由 Niko Matsakis 提交于
to pass in the appropriate ast::generics etc
-
由 Niko Matsakis 提交于
exclusively stored in the where clauses.
-
- 21 2月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 19 2月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 16 2月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 11 2月, 2015 1 次提交
-
-
由 Felix S. Klock II 提交于
immediately surrounding a node that is a terminating_scope (e.g. statements, looping forms) during which the destructors run (the destructors for temporaries from the execution of that node, that is). Introduced DestructionScopeData newtype wrapper around ast::NodeId, to preserve invariant that FreeRegion and ScopeChain::BlockScope carry destruction scopes (rather than arbitrary CodeExtents). Insert DestructionScope and block Remainder into enclosing CodeExtents hierarchy. Add more doc for DestructionScope, complete with ASCII art. Switch to constructing DestructionScope rather than Misc in a number of places, mostly related to `ty::ReFree` creation, and use destruction-scopes of node-ids at various calls to liberate_late_bound_regions. middle::resolve_lifetime: Map BlockScope to DestructionScope in `fn resolve_free_lifetime`. Add the InnermostDeclaringBlock and InnermostEnclosingExpr enums that are my attempt to clarify the region::Context structure, and that later commmts build upon. Improve the debug output for `CodeExtent` attached to `ty::Region::ReScope`. Loosened an assertion in `rustc_trans::trans::cleanup` to account for `DestructionScope`. (Perhaps this should just be switched entirely over to `DestructionScope`, rather than allowing for either `Misc` or `DestructionScope`.) ---- Even though the DestructionScope is new, this particular commit should not actually change the semantics of any current code.
-
- 06 2月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 03 2月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 01 2月, 2015 1 次提交
-
-
由 Alfie John 提交于
-
- 31 1月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commits adds an associated type to the `FromStr` trait representing an error payload for parses which do not succeed. The previous return value, `Option<Self>` did not allow for this form of payload. After the associated type was added, the following attributes were applied: * `FromStr` is now stable * `FromStr::Err` is now stable * `FromStr::from_str` is now stable * `StrExt::parse` is now stable * `FromStr for bool` is now stable * `FromStr for $float` is now stable * `FromStr for $integral` is now stable * Errors returned from stable `FromStr` implementations are stable * Errors implement `Display` and `Error` (both impl blocks being `#[stable]`) Closes #15138
-
- 29 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 27 1月, 2015 1 次提交
-
-
由 Felix S. Klock II 提交于
This new variant introduces finer-grain code extents, i.e. we now track that a binding lives only for a suffix of a block, and (importantly) will be dropped when it goes out of scope *before* the bindings that occurred earlier in the block. Both of these notions are neatly captured by marking the block (and each suffix) as an enclosing scope of the next suffix beneath it. This is work that is part of the foundation for issue #8861. (It actually has been seen in earlier posted pull requests; I have just factored it out into its own PR to ease my own rebasing.) ---- These finer grained scopes do mean that some code is newly rejected by `rustc`; for example: ```rust let mut map : HashMap<u8, &u8> = HashMap::new(); let tmp = Box::new(2); map.insert(43, &*tmp); ``` This will now fail to compile with a message that `*tmp` does not live long enough, because the scope of `tmp` is now strictly smaller than that of `map`, and the use of `&u8` in map's type requires that the borrowed references are all to data that live at least as long as the map. The usual fix for a case like this is to move the binding for `tmp` up above that of `map`; note that you can still leave the initialization in the original spot, like so: ```rust let tmp; let mut map : HashMap<u8, &u8> = HashMap::new(); tmp = box 2; map.insert(43, &*tmp); ``` Similarly, one can encounter an analogous situation with `Vec`: one would need to rewrite: ```rust let mut vec = Vec::new(); let tmp = 'c'; vec.push(&tmp); ``` as: ``` let tmp; let mut vec = Vec::new(); tmp = 'c'; vec.push(&tmp); ``` ---- In some corner cases, it does not suffice to reorder the bindings; in particular, when the types for both bindings need to reflect exactly the *same* code extent, and a parent/child relationship between them does not work. In pnkfelix's experience this has arisen most often when mixing uses of cyclic data structures while also allowing a lifetime parameter `'a` to flow into a type parameter context where the type is *invariant* with respect to the type parameter. An important instance of this is `arena::TypedArena<T>`, which is invariant with respect to `T`. (The reason that variance is relevant is this: *if* `TypedArena` were covariant with respect to its type parameter, then we could assign it the longer lifetime when it is initialized, and then convert it to a subtype (via covariance) with a shorter lifetime when necessary. But `TypedArena` is invariant with respect to its type parameter, and thus if `S` is a subtype of `T` (in particular, if `S` has a lifetime parameter that is shorter than that of `T`), then a `TypedArena<S>` is unrelated to `TypedArena<T>`.) Concretely, consider code like this: ```rust struct Node<'a> { sibling: Option<&'a Node<'a>> } struct Context<'a> { // because of this field, `Context<'a>` is invariant with respect to `'a`. arena: &'a TypedArena<Node<'a>>, ... } fn new_ctxt<'a>(arena: &'a TypedArena<Node<'a>>) -> Context<'a> { ... } fn use_ctxt<'a>(fcx: &'a Context<'a>) { ... } let arena = TypedArena::new(); let ctxt = new_ctxt(&arena); use_ctxt(&ctxt); ``` In these situations, if you try to introduce two bindings via two distinct `let` statements, each is (with this commit) assigned a distinct extent, and the region inference system cannot find a single region to assign to the lifetime `'a` that works for both of the bindings. So you get an error that `ctxt` does not live long enough; but moving its binding up above that of `arena` just shifts the error so now the compiler complains that `arena` does not live long enough. SO: What to do? The easiest fix in this case is to ensure that the two bindings *do* get assigned the same static extent, by stuffing both bindings into the same let statement, like so: ```rust let (arena, ctxt): (TypedArena, Context); arena = TypedArena::new(); ctxt = new_ctxt(&arena); use_ctxt(&ctxt); ``` Due to the new code rejections outlined above, this is a ... [breaking-change]
-
- 26 1月, 2015 2 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
- 20 1月, 2015 3 次提交
-
-
由 Ariel Ben-Yehuda 提交于
-
由 Ariel Ben-Yehuda 提交于
-
由 Jorge Aparicio 提交于
-
- 08 1月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 07 1月, 2015 3 次提交
-
-
由 Sean McArthur 提交于
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
-
由 Nick Cameron 提交于
-
由 Corey Richardson 提交于
-
- 06 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 04 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 03 1月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 503][rfc] which is a stabilization story for the prelude. Most of the RFC was directly applied, removing reexports. Some reexports are kept around, however: * `range` remains until range syntax has landed to reduce churn. * `Path` and `GenericPath` remain until path reform lands. This is done to prevent many imports of `GenericPath` which will soon be removed. * All `io` traits remain until I/O reform lands so imports can be rewritten all at once to `std::io::prelude::*`. This is a breaking change because many prelude reexports have been removed, and the RFC can be consulted for the exact list of removed reexports, as well as to find the locations of where to import them. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md [breaking-change] Closes #20068
-
- 30 12月, 2014 6 次提交
-
-
由 Niko Matsakis 提交于
1. Produced more unique types than is necessary. This increases memory consumption. 2. Linking the type parameter to its definition *seems* like a good idea, but it encourages reliance on the bounds listing. 3. It made pretty-printing harder and in particular was causing bad error messages when errors occurred before the `TypeParameterDef` entries were fully stored.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 503][rfc] which is a stabilization story for the prelude. Most of the RFC was directly applied, removing reexports. Some reexports are kept around, however: * `range` remains until range syntax has landed to reduce churn. * `Path` and `GenericPath` remain until path reform lands. This is done to prevent many imports of `GenericPath` which will soon be removed. * All `io` traits remain until I/O reform lands so imports can be rewritten all at once to `std::io::prelude::*`. This is a breaking change because many prelude reexports have been removed, and the RFC can be consulted for the exact list of removed reexports, as well as to find the locations of where to import them. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md [breaking-change] Closes #20068
-
- 29 12月, 2014 4 次提交
-
-
由 Huon Wilson 提交于
This makes sty only 32 bytes on machines with 64-bit pointers.
-
由 Huon Wilson 提交于
This cuts the ty_bare_fn variant to 48 bytes rather than 56. There doesn't seem to be a noticable memory usage decrease from this.
-
由 Huon Wilson 提交于
This reduces memory use for building librustc with -O from 1.88 to 1.76 GB.
-
由 Huon Wilson 提交于
This current inflates memory use more than 3 times.
-
- 23 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 22 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 19 12月, 2014 1 次提交
-
-
由 Jorge Aparicio 提交于
-