- 08 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 07 4月, 2014 9 次提交
-
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
Broken on BSD. #12460
-
由 Brian Anderson 提交于
-
由 Steven Fackler 提交于
-
由 Steven Fackler 提交于
There's a little more allocation here and there now since from_utf8_owned can't be used with Vec.
-
- 06 4月, 2014 5 次提交
-
-
由 Flavio Percoco 提交于
Rust currently defaults to `RelocPIC` regardless. This patch adds a new codegen option that allows choosing different relocation-model. The available models are: - default (Use the target-specific default model) - static - pic - no-pic For a more detailed information use `llc --help`
-
由 Eduard Burtescu 提交于
-
由 Alex Crichton 提交于
In summary these are some example transitions this change makes: 'a || => ||: 'a proc:Send() => proc():Send The intended syntax for closures is to put the lifetime bound not at the front but rather in the list of bounds. Currently there is no official support in the AST for bounds that are not 'static, so this case is currently specially handled in the parser to desugar to what the AST is expecting. Additionally, this moves the bounds on procedures to the correct position, which is after the argument list. The current grammar for closures and procedures is: procedure := 'proc' [ '<' lifetime-list '>' ] '(' arg-list ')' [ ':' bound-list ] [ '->' type ] closure := [ 'unsafe' ] ['<' lifetime-list '>' ] '|' arg-list '|' [ ':' bound-list ] [ '->' type ] lifetime-list := lifetime | lifetime ',' lifetime-list arg-list := ident ':' type | ident ':' type ',' arg-list bound-list := bound | bound '+' bound-list bound := path | lifetime This does not currently handle the << ambiguity in `Option<<'a>||>`, I am deferring that to a later patch. Additionally, this removes the support for the obsolete syntaxes of ~fn and &fn. Closes #10553 Closes #10767 Closes #11209 Closes #11210 Closes #11211
-
由 Alex Crichton 提交于
This was quite a curious bug on windows, and the details can be found in the comment I added to src/librustc/back/link.rs
-
由 Benjamin Herr 提交于
-
- 05 4月, 2014 6 次提交
-
-
由 Felix S. Klock II 提交于
All it checks, unfortunately, is that you actually printed at least two lines for crateA paths and at least one line for crateB paths. But that's enough to capture the spirit of the bug, I think. I did not bother trying to verify that the paths themselves reflected where the crates end up.
-
由 Kevin Butler 提交于
-
由 Huon Wilson 提交于
This pass is purely AST based, and by running it earlier we emit more useful error messages, e.g. type inference fails in the case of `let r = break;` with few constraints on `r`, but its more useful to be told that the `break` is outside a loop (rather than a type error) when it is. Closes #13292.
-
由 Alex Crichton 提交于
-
由 Timothée Ravier 提交于
From the 0.10 changelog: * The inner attribute syntax has changed from `#[foo];` to `#![foo]`.
-
由 Corey Richardson 提交于
-
- 04 4月, 2014 10 次提交
-
-
由 Huon Wilson 提交于
concat_idents! is not as useful as it could be, due to macros only being allowed in limited places, and hygiene, so lets feature gate it until we make a decision about it. cc #13294
-
由 Erick Tryzelaar 提交于
This fixes #13238. It avoids an infinite loop when compiling the tests with `-g`. Without this change, the debuginfo on `black_box` prevents the method from being inlined, which allows llvm to convert `silent_recurse` into a tail-call. This then loops forever instead of consuming all the stack like it is supposed to. This patch forces inlining `black_box`, which triggers the right error.
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
It's surprising that `RefCell::get()` is implicitly doing a clone on a value. This patch removes it and replaces all users with either `.borrow()` when we can autoderef, or `.borrow().clone()` when we cannot.
-
由 Daniel Micay 提交于
This was missed when dropping the null-termination from our string types. An explicit null byte can still be placed anywhere in a string if desired, but there's no reason to stick one at the end of every string constant.
-
由 Alex Crichton 提交于
-
由 Brian Anderson 提交于
This also changes some of the download links in the documentation to 'nightly'.
-
由 Daniel Micay 提交于
1778b636 provided the guarantee of no `exchange_free` calls for ~ZeroSizeType, so a sentinel can now be used without overhead. Closes #11998
-
由 klutzy 提交于
-
由 klutzy 提交于
Fixes #10474
-
- 03 4月, 2014 2 次提交
-
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
This commit tightens up the restriction on types used to index slices to require exactly `uint` indices. Previously any integral type was accepted, but this leads to a few subtle problems: * 64-bit indices don't make much sense on 32-bit systems * Signed indices for slices used as negative indexing isn't implemented This was discussed at the recent work week, and also has some discussion on issue #10453. Closes #10453
-
- 02 4月, 2014 1 次提交
-
-
由 Huon Wilson 提交于
There are a few instances of them in tests which are using functions from std etc. that still are using ~[].
-
- 01 4月, 2014 6 次提交
-
-
由 Huon Wilson 提交于
The various ...Rng::new() methods can hit IO errors from the OSRng they use, and it seems sensible to expose them at a higher level. Unfortunately, writing e.g. `StdRng::new().unwrap()` gives a much poorer error message than if it failed internally, but this is a problem with all `IoResult`s.
-
由 Gábor Lehel 提交于
this is useful for macros like vec! which construct containers
-
由 Alex Crichton 提交于
This commit deals with the fallout of the previous change by making tuples structs have public fields where necessary (now that the fields are private by default).
-
由 Alex Crichton 提交于
This is a continuation of the work done in #13184 to make struct fields private by default. This commit finishes RFC 4 by making all tuple structs have private fields by default. Note that enum variants are not affected. A tuple struct having a private field means that it cannot be matched on in a pattern match (both refutable and irrefutable), and it also cannot have a value specified to be constructed. Similarly to private fields, switching the type of a private field in a tuple struct should be able to be done in a backwards compatible way. The one snag that I ran into which wasn't mentioned in the RFC is that this commit also forbids taking the value of a tuple struct constructor. For example, this code now fails to compile: mod a { pub struct A(int); } let a: fn(int) -> a::A = a::A; //~ ERROR: first field is private Although no fields are bound in this example, it exposes implementation details through the type itself. For this reason, taking the value of a struct constructor with private fields is forbidden (outside the containing module). RFC: 0004-private-fields
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-