- 31 10月, 2014 1 次提交
-
-
由 Jakub Bukaj 提交于
-
- 30 10月, 2014 7 次提交
-
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
Diagnostics such as the following ``` mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>` <anon>:6 let a: Result<uint, ()> = None; ^~~~ mismatched types: expected `&mut <generic #2>`, found `uint` <anon>:7 f(42u); ^~~ ``` tend to be fairly unappealing to new users. While specific type var IDs are valuable in diagnostics that deal with more than one such variable, in practice many messages only mention one. In those cases, leaving out the specific number makes the messages slightly less terrifying. In addition, type variables have been changed to use the type hole syntax `_` in diagnostics. With a variable ID, they're printed as `_#id` (e.g. `_#1`). In cases where the ID is left out, it's simply `_`. Integer and float variables have an additional suffix after the number, e.g. `_#1i` or `_#3f`.
-
由 bors 提交于
This in-progress PR implements https://github.com/rust-lang/rust/issues/17489. I made the code changes in this commit, next is to go through alllllllll the documentation and fix various things. - Rename column headings as appropriate, `# Panics` for panic conditions and `# Errors` for `Result`s. - clean up usage of words like 'fail' in error messages Anything else to add to the list, @aturon ? I think I should leave the actual functions with names like `slice_or_fail` alone, since you'll get to those in your conventions work? I'm submitting just the code bits now so that we can see it separately, and I also don't want to have to keep re-building rust over and over again if I don't have to
😉 Listing all the bits so I can remember as I go: - [x] compiler-rt - [x] compiletest - [x] doc - [x] driver - [x] etc - [x] grammar - [x] jemalloc - [x] liballoc - [x] libarena - [x] libbacktrace - [x] libcollections - [x] libcore - [x] libcoretest - [x] libdebug - [x] libflate - [x] libfmt_macros - [x] libfourcc - [x] libgetopts - [x] libglob - [x] libgraphviz - [x] libgreen - [x] libhexfloat - [x] liblibc - [x] liblog - [x] libnative - [x] libnum - [x] librand - [x] librbml - [x] libregex - [x] libregex_macros - [x] librlibc - [x] librustc - [x] librustc_back - [x] librustc_llvm - [x] librustdoc - [x] librustrt - [x] libsemver - [x] libserialize - [x] libstd - [x] libsync - [x] libsyntax - [x] libterm - [x] libtest - [x] libtime - [x] libunicode - [x] liburl - [x] libuuid - [x] llvm - [x] rt - [x] test -
由 Steve Klabnik 提交于
This includes updating the language items and marking what needs to change after a snapshot. If you do not use the standard library, the language items you need to implement have changed. For example: ```rust #[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} } ``` is now ```rust #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } ``` Related, lesser-implemented language items `fail` and `fail_bounds_check` have become `panic` and `panic_bounds_check`, as well. These are implemented by `libcore`, so it is unlikely (though possible!) that these two renamings will affect you. [breaking-change] Fix test suite
-
由 bors 提交于
Fixes #18034 3 bugs fixed.
-
- 29 10月, 2014 14 次提交
-
-
由 Steve Klabnik 提交于
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]
-
由 bors 提交于
Fixes #17969
-
由 bors 提交于
[breaking-change] (for syntax-extensions) - Token variant identifiers have been converted to PascalCase for consistency with Rust coding standards - Some free-functions in `syntax::token` have been converted to methods on `syntax::token::Token`: - `can_begin_expr` -> `Token::can_begin_expr` - `close_delimiter_for` -> `Token::get_close_delimiter` - `is_lit` -> `Token::is_lit` - `is_ident` -> `Token::is_ident` - `is_path` -> `Token::is_path` - `is_plain_ident` -> `Token::is_plain_ident` - `is_lifetime` -> `Token::is_lifetime` - `is_mutability` -> `Token::is_mutability` - `to_binop` -> `Token::to_binop` - `is_keyword` -> `Token::is_keyword` - `is_any_keyword` -> `Token:is_any_keyword` - `is_strict_keyword` -> `Token::is_strict_keyword` - `is_reserved_keyword` -> `Token::is_reserved_keyword` - `mtwt_token_eq` -> `Token::mtwt_eq` - `token::Ident` now takes an enum instead of a boolean for clarity - `token::{to_string, binop_to_string}` were moved to `pprust::{token_to_string, binop_to_string}`
-
由 bors 提交于
Some minor wording fixes to the Closures chapter; my brain tripped a few times when reading it, so I tried to come up with something a bit smoother. I’m not a native speaker, so please do review this critically.
-
由 Daniel Micay 提交于
This reverts commit c245c5bb. Parallel code generation generates invalid code for librand, which is caught by recent versions of binutils.
-
由 bors 提交于
We now instead use a fresh variable for expressions that diverge. Closes #14973. Closes #13847. [Work in progress] cc @nikomatsakis
-
由 bors 提交于
This PR changes the signature of several methods from `foo(self, ...)` to `foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage of these methods due to the autoref nature of `method.call()`s. This PR also removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These changes break any use of the extension traits for generic programming, but those traits are not meant to be used for generic programming in the first place. In the whole rust distribution there was only one misuse of a extension trait as a bound, which got corrected (the bound was unnecessary and got removed) as part of this PR. I've kept the commits as small and self-contained as possible for reviewing sake, but I can squash them when the review is over. See this [table] to get an idea of what's left to be done. I've already DSTified [`Show`][show] and I'm working on `Hash`, but bootstrapping those changes seem to require a more recent snapshot (#18259 does the trick) r? @aturon cc #16918 [show]: https://github.com/japaric/rust/commits/show [table]: https://docs.google.com/spreadsheets/d/1MZ_iSNuzsoqeS-mtLXnj9m0hBYaH5jI8k9G_Ud8FT5g/edit?usp=sharing
-
由 Steve Klabnik 提交于
Fixes #17969
-
由 bors 提交于
Just to have it somewhere to point to. Updating it will not automatically update the one on static.rust-lang.org.
-
由 Jakub Bukaj 提交于
-
由 Brian Anderson 提交于
-
由 Jakub Bukaj 提交于
-
由 Jakub Bukaj 提交于
We now instead use a fresh variable for expressions that diverge.
-
- 28 10月, 2014 18 次提交
-
-
由 bors 提交于
Closes #18218
-
由 bors 提交于
Avoid O(n^2) performance by reconsidering the full set of obligations only when we are about to report an error (#18208). I found it is still important to consider the full set in order to make tests like `let x: Vec<_> = obligations.iter().collect()` work. I think we lack the infrastructure to write a regression test for this, but when I did manual testing I found a massive reduction in type-checking time for extreme examples like those found in #18208 vs stage0. f? @dotdash
-
由 Niko Matsakis 提交于
Avoid O(n^2) performance by reconsidering the full set of obligations only when we are about to report an error (#18208). I found it is still important to consider the full set in order to make tests like `let x: Vec<_> = obligations.iter().collect()` work.
-
由 bors 提交于
- shrink_to_fit example is now more clear by asserting the capacity value - annotation [0, mid) changed for [0, mid]
-
由 bors 提交于
This adds impls of Eq/Ord/PartialEq/PartialOrd/Show/Default to Arc<T>, and it also removes the `Send + Sync` bound on the `Clone` impl of Arc to make it more deriving-friendly. The `Send + Sync` requirement is still enforce on construction, of course!
-
由 bors 提交于
The goal here is to make it easier to add new platform definitions, especially when the additions are programmatic (ie: in build scripts).
-
由 Alex Crichton 提交于
This adds impls of Eq/Ord/PartialEq/PartialOrd/Show/Default to Arc<T>, and it also removes the `Send + Sync` bound on the `Clone` impl of Arc to make it more deriving-friendly. The `Send + Sync` requirement is still enforce on construction, of course!
-
由 Brendan Zabarauskas 提交于
-
由 Brendan Zabarauskas 提交于
-
由 Brendan Zabarauskas 提交于
-
由 Brendan Zabarauskas 提交于
-
由 bors 提交于
This allows unboxed closures that reference free type/region parameters to be monomorphized correctly in trans. It was necessary to make `ty_unboxed_closure` carry around a `Substs` to accomplish this. Plumbing this through typeck revealed several areas where type/region parameters in unboxed closure types are possibly not being handled correctly. Since my goal was just to fix trans, I decided to leave FIXME comments on areas that still need attention and seek feedback on the best way to clean them up, possibly as a follow-up PR. Closes #16791
-
由 Brian Koropoff 提交于
-
由 Brian Koropoff 提交于
This adds a `Substs` field to `ty_unboxed_closure` and plumbs basic handling of it throughout the compiler. trans now correctly monomorphizes captured free variables and llvm function defs. This fixes uses of unboxed closures which reference a free type or region parameter from their environment in either their signature or free variables. Closes #16791
-
由 Jorge Aparicio 提交于
This PR changes the signature of several methods from `foo(self, ...)` to `foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage of these methods due to the autoref nature of `method.call()`s. This PR also removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These changes break any use of the extension traits for generic programming, but those traits are not meant to be used for generic programming in the first place. In the whole rust distribution there was only one misuse of a extension trait as a bound, which got corrected (the bound was unnecessary and got removed) as part of this PR. [breaking-change]
-
由 bors 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-