bors [Sat, 30 Aug 2014 10:51:26 +0000 (10:51 +0000)]
auto merge of #16419 : huonw/rust/pretty-expanded-hygiene, r=pnkfelix
Different Identifiers and Names can have identical textual representations, but different internal representations, due to the macro hygiene machinery (syntax contexts and gensyms). This provides a way to see these internals by compiling with `--pretty expanded,hygiene`.
This is useful for debugging & hacking on macros (e.g. diagnosing https://github.com/rust-lang/rust/issues/15750/https://github.com/rust-lang/rust/issues/15962 likely would've been faster with this functionality).
Huon Wilson [Mon, 11 Aug 2014 12:01:37 +0000 (22:01 +1000)]
rustc: implement a pretty mode to print ident/name's ctxt & gensyms.
`--pretty expanded,hygiene` is helpful with debugging macro issues,
since two identifiers/names can be textually the same, but different
internally (resulting in weird "undefined variable" errors).
bors [Fri, 29 Aug 2014 22:16:20 +0000 (22:16 +0000)]
auto merge of #15773 : P1start/rust/style-lints, r=alexcrichton
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.
This also adds support for lint groups to the compiler. Lint groups are a way of grouping a number of lints together under one name. For example, this also defines a default lint for naming conventions, named `bad_style`. Writing `#[allow(bad_style)]` is equivalent to writing `#[allow(non_camel_case_types, non_snake_case, non_uppercase_statics)]`. These lint groups can also be defined as a compiler plugin using the new `Registry::register_lint_group` method.
This also adds two built-in lint groups, `bad_style` and `unused`. The contents of these groups can be seen by running `rustc -W help`.
Add lint groups; define built-in lint groups `bad_style` and `unused`
This adds support for lint groups to the compiler. Lint groups are a way of
grouping a number of lints together under one name. For example, this also
defines a default lint for naming conventions, named `bad_style`. Writing
`#[allow(bad_style)]` is equivalent to writing
`#[allow(non_camel_case_types, non_snake_case, non_uppercase_statics)]`. These
lint groups can also be defined as a compiler plugin using the new
`Registry::register_lint_group` method.
This also adds two built-in lint groups, `bad_style` and `unused`. The contents
of these groups can be seen by running `rustc -W help`.
Unify non-snake-case lints and non-uppercase statics lints
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.
bors [Fri, 29 Aug 2014 19:21:12 +0000 (19:21 +0000)]
auto merge of #15955 : nikomatsakis/rust/issue-5527-new-inference-scheme, r=pcwalton
The inference scheme proposed in <http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-experimental-new-type-inference-scheme-for-rust/>.
This is theoretically a [breaking-change]. It is possible that you may encounter type checking errors, particularly related to closures or functions with higher-ranked lifetimes or object types. Adding more explicit type annotations should help the problem. However, I have not been able to make an example that *actually* successfully compiles with the older scheme and fails with the newer scheme.
bors [Fri, 29 Aug 2014 15:41:20 +0000 (15:41 +0000)]
auto merge of #16767 : SiegeLord/rust/reexported_methods, r=cmr
Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator` impl.
# Changes to `core::result`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator` impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants.
bors [Thu, 28 Aug 2014 22:11:18 +0000 (22:11 +0000)]
auto merge of #16626 : ruud-v-a/rust/duration-reform, r=brson
This changes the internal representation of `Duration` from
days: i32,
secs: i32,
nanos: u32
to
secs: i64,
nanos: i32
This resolves #16466. Note that `nanos` is an `i32` and not `u32` as suggested, because `i32` is easier to deal with, and it is not exposed anyway. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds.
A few remarks:
- Negating `MIN` is impossible. I chose to return `MAX` as `-MIN`, but it is one nanosecond less than the actual negation. Is this the desired behaviour?
- In `std::io::timer`, some functions accept a `Duration`, which is internally converted into a number of milliseconds. However, the range of `Duration` is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?
- Negative durations are not formatted correctly, but they were not formatted correctly before either.
Joseph Crail [Tue, 26 Aug 2014 23:46:20 +0000 (19:46 -0400)]
Fix issue #15826.
The implemented fix rounds half-way cases away from zero as described in
the original comments.
This rounding algorithm is sometimes called arithmetic rounding. It is
described further here:
http://en.wikipedia.org/wiki/Rounding#Round_half_away_from_zero
I also added several new tests to prevent regressions.
Most of the module is marked as stable or unstable; most of the unstable
items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator`
impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including
`iter`, `as_slice`, and variants.
Most of the module is marked as stable or unstable; most of the unstable
items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use
or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer
for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator`
impl.
1. type parameters can have lifetime bounds and objects can close over borrowed values, presuming that they have suitable bounds.
2. objects must have a bound, though it may be derived from the trait itself or from a `Send` bound.
3. all types must be well-formed.
4. type parameters and lifetime parameters may themselves have lifetimes as bounds. Something like `T:'a` means "the type T outlives 'a`" and something like `'a:'b`" means "'a outlives 'b". Outlives here means "all borrowed data has a lifetime at least as long".
This is a [breaking-change]. The most common things you have to fix after this change are:
1. Introduce lifetime bounds onto type parameters if your type (directly or indirectly) contains a reference. Thus a struct like `struct Ref<'a, T> { x: &'a T }` would be changed to `struct Ref<'a, T:'a> { x: &'a T }`.
2. Introduce lifetime bounds onto lifetime parameters if your type contains a double reference. Thus a type like `struct RefWrapper<'a, 'b> { r: &'a Ref<'b, int> }` (where `Ref` is defined as before) would need to be changed to `struct RefWrapper<'a, 'b:'a> { ... }`.
2. Explicitly give object lifetimes in structure definitions. Most commonly, this means changing something like `Box<Reader>` to `Box<Reader+'static>`, so as to indicate that this is a reader without any borrowed data. (Note: you may wish to just change to `Box<Reader+Send>` while you're at it; it's a more restrictive type, technically, but means you can send the reader between threads.)
The intuition for points 1 and 2 is that a reference must never outlive its referent (the thing it points at). Therefore, if you have a type `&'a T`, we must know that `T` (whatever it is) outlives `'a`. And so on.
bors [Wed, 27 Aug 2014 21:31:13 +0000 (21:31 +0000)]
auto merge of #16757 : steveklabnik/rust/lets_not_lie_in_the_concurrency_guide, r=alexcrichton
This cleans up blatant lies in the concurrency guide, and modernizes it
a bit. There's a lot more to do, but until I get to it, let's make it a
little bit better.
Steve Klabnik [Tue, 26 Aug 2014 01:15:20 +0000 (21:15 -0400)]
Fix lies in the concurrency guide.
This cleans up blatant lies in the concurrency guide, and modernizes it
a bit. There's a lot more to do, but until I get to it, let's make it a
little bit better.
bors [Wed, 27 Aug 2014 19:46:14 +0000 (19:46 +0000)]
auto merge of #16797 : nikomatsakis/rust/remove-invalid-spsc_queue-test, r=alexcrichton
This test seems to read freed memory -- the peeked variable points into the queue, but then the pop operation removes the node from the queue and moves the enclosing `T` elsewhere, invalidating the `peeked` pointer.
bors [Wed, 27 Aug 2014 07:46:17 +0000 (07:46 +0000)]
auto merge of #16724 : tshepang/rust/misleading, r=brson
We have to specify the module and the function name in the example where
the module shares a crate with the executable as well, so remove the
redundant (and potentially confusing) mention.
bors [Wed, 27 Aug 2014 00:31:25 +0000 (00:31 +0000)]
auto merge of #16704 : flugsio/rust/fix-rustc-ice-lint-underscores-only, r=brson
Fix for type identifiers with only underscores (two or more), I assume they doesn't count as camel case.
```rust
type __ = int;
fn main() {
}
```
```
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'index out of bounds: the len is 0 but the index is 0', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/librustc/lib.rs:1
SiegeLord [Tue, 26 Aug 2014 18:41:25 +0000 (14:41 -0400)]
Always insert methods into the search index, even if we're currently in a private module.
Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.
projects / rust.git / log