https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=master 2014-11-18T12:32:43+00:00 2014-11-18T12:32:43+00:00 Niko Matsakis niko@alum.mit.edu 2014-11-16T01:30:33+00:00 urn:sha1:dc6e414e6f85293aceca3357e2466bcc4bcf425c 2014-11-05T03:44:02+00:00 Luqman Aden laden@csclub.uwaterloo.ca 2014-11-05T03:31:20+00:00 urn:sha1:20c1945c51e6ece5dd2cbab1cb06abd93b8778b4 2014-10-29T15:43:07+00:00 Steve Klabnik steve@steveklabnik.com 2014-10-09T19:17:22+00:00 urn:sha1:7828c3dd2858d8f3a0448484d8093e22719dbda0 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] 2014-10-15T11:17:34+00:00 Ariel Ben-Yehuda ariel.byd@gmail.com 2014-10-14T20:36:11+00:00 urn:sha1:01d693b1cdc8b2b6aee2b78f0ef89540427029be Use the integer sizes LLVM uses, rather than having random projections laying around. Sizes are u64, Alignments are u32, C_*int is target-dependent but 64-bit is fine (the int -> C_int conversion is non-precision-losing, but it can be preceded by `as int` conversions which are, so it is somewhat ugly. However, being able to suffix a `u` to properly infer integer types is nice). 2014-09-08T12:28:24+00:00 Eduard Burtescu edy.burt@gmail.com 2014-09-06T16:13:04+00:00 urn:sha1:f7a997be05e364248521ee4d11ab57fcb2e99a40 2014-09-08T12:28:23+00:00 Eduard Burtescu edy.burt@gmail.com 2014-04-22T12:56:37+00:00 urn:sha1:28be695b2c727b380d075986cbe52e699761b56e 2014-09-05T16:18:53+00:00 Stuart Pernsteiner spernsteiner@mozilla.com 2014-09-05T16:18:53+00:00 urn:sha1:cf35cb365a4efee53f6372095aaff4798544bf94 2014-08-29T21:10:05+00:00 P1start rewi-github@whanau.org 2014-07-18T12:45:17+00:00 urn:sha1:de7abd88244a9fe7033cb71e22af0601d1b811b9 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] 2014-07-25T23:06:44+00:00 Luqman Aden me@luqman.ca 2014-07-25T23:06:44+00:00 urn:sha1:17256197a963561d02faff0634e11d7a079e7105 2014-07-14T19:27:08+00:00 Brian Anderson banderson@mozilla.com 2014-07-08T00:58:01+00:00 urn:sha1:3096d9bf946d2e3e74b24dbb4a5d116a5d9ac7c7 This makes it much saner for clients to use the library since they don't have to worry about shadowing one llvm with another.