Commit Graph

1961 Commits

Author SHA1 Message Date
Patrick Walton
7a80fa647a test: Remove @str from the test suite 2014-02-02 01:44:49 +11:00
Huon Wilson
a9f73b5e3d Remove the obsolete handler for impl A;.
This is has been obsolete for quite a while now (including a release),
so removing the special handling seems fine. (The error message is quite
good still anyway.)

Fixes #9580.
2014-01-31 21:43:09 -08:00
Huon Wilson
6c52e72214 Add test for sensible #[start] error message.
Fixes #9575.
2014-01-31 21:43:09 -08:00
OGINO Masanori
ed5b897899 Add test cases for #4063.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
2014-01-31 21:43:09 -08:00
Virgile Andreani
b9a026afba Fix minor doc typos 2014-01-31 21:43:07 -08:00
Niko Matsakis
81d8328517 Introduce marker types for indicating variance and for opting out
of builtin bounds.

Fixes #10834.
Fixes #11385.
cc #5922.
2014-01-31 21:18:48 -05:00
bors
535e806841 auto merge of #11929 : FlaPer87/rust/issue-11681, r=huonw
closes #11681
2014-01-31 05:36:31 -08:00
Eduard Burtescu
7d967741c3 Implement default type parameters in generics. 2014-01-30 19:28:41 +02:00
Flavio Percoco
0d0205a577 Add test case for issue #11681 2014-01-30 12:17:58 +01:00
bors
056363ff36 auto merge of #11839 : typelist/rust/issue3008, r=huonw
It was possible to trigger a stack overflow in rustc because the routine used to verify enum representability,
type_structurally_contains, would recurse on inner types until hitting the original type. The overflow condition was when a different structurally recursive type (enum or struct) was contained in the type being checked.

I suspect my solution isn't as efficient as it could be. I pondered adding a cache of previously-seen types to avoid duplicating work (if enums A and B both contain type C, my code goes through C twice), but I didn't want to do anything that may not be necessary.

I'm a new contributor, so please pay particular attention to any unidiomatic code, misuse of terminology, bad naming of tests, or similar horribleness :)

Updated to verify struct representability as well.

Fixes #3008.
Fixes #3779.
2014-01-29 22:21:29 -08:00
bors
3cb72a3655 auto merge of #11672 : bjz/rust/remove-times, r=brson
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal (which I liked) was then lost after `do` was disabled for closures. It's time to let this one go.
2014-01-29 20:06:36 -08:00
Brendan Zabarauskas
729060dbb9 Remove Times trait
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal was then lost after `do` was disabled for closures. It's time to let this one go.
2014-01-30 14:52:25 +11:00
Johannes Muenzel
b46c0daa7b Add compile-fail tests for non-representable structs and enums 2014-01-29 20:33:51 -05:00
bors
f84b7291e7 auto merge of #11776 : FlaPer87/rust/issue-11681-static-lifetime, r=nikomatsakis
Closes #11681
Closes #11854
2014-01-29 15:01:43 -08:00
Flavio Percoco
cb5d7236f1 Fixes temporary lifetime computation for static items
closes: #11854
2014-01-29 22:39:33 +01:00
bors
c3ae182d5c auto merge of #11754 : alexcrichton/rust/unused-result, r=brson
The general consensus is that we want to move away from conditions for I/O, and I propose a two-step plan for doing so:

1. Warn about unused `Result` types. When all of I/O returns `Result`, it will require you inspect the return value for an error *only if* you have a result you want to look at. By default, for things like `write` returning `Result<(), Error>`, these will all go silently ignored. This lint will prevent blind ignorance of these return values, letting you know that there's something you should do about them.

2. Implement a `try!` macro:

```
macro_rules! try( ($e:expr) => (match $e { Ok(e) => e, Err(e) => return Err(e) }) )
```

With these two tools combined, I feel that we get almost all the benefits of conditions. The first step (the lint) is a sanity check that you're not ignoring return values at callsites. The second step is to provide a convenience method of returning early out of a sequence of computations. After thinking about this for awhile, I don't think that we need the so-called "do-notation" in the compiler itself because I think it's just *too* specialized. Additionally, the `try!` macro is super lightweight, easy to understand, and works almost everywhere. As soon as you want to do something more fancy, my answer is "use match".

Basically, with these two tools in action, I would be comfortable removing conditions. What do others think about this strategy?

----

This PR specifically implements the `unused_result` lint. I actually added two lints, `unused_result` and `unused_must_use`, and the first commit has the rationale for why `unused_result` is turned off by default.
2014-01-29 09:46:34 -08:00
bors
e1580f6d09 auto merge of #11868 : bytbox/rust/remove-do, r=alexcrichton
Fixes #10815.
2014-01-29 08:21:38 -08:00
Scott Lawrence
3dbc1c34e6 Remove do keyword from test/ 2014-01-29 09:15:42 -05:00
Flavio Percoco
279fe0fa76 Treat unary struct and enum variants as rvalues
Closes #11681
2014-01-29 14:15:24 +01:00
Alex Crichton
9896beb5b5 Implement an unused_result lint
I attempted to implement the lint in two steps. My first attempt was a
default-warn lint about *all* unused results. While this attempt did indeed find
many possible bugs, I felt that the false-positive rate was too high to be
turned on by default for all of Rust.

My second attempt was to make unused-result a default-allow lint, but allow
certain types to opt-in to the notion of "you must use this". For example, the
Result type is now flagged with #[must_use]. This lint about "must use" types is
warn by default (it's different from unused-result).

The unused_must_use lint had a 100% hit rate in the compiler, but there's not
that many places that return Result right now. I believe that this lint is a
crucial step towards moving away from conditions for I/O (because all I/O will
return Result by default). I'm worried that this lint is a little too specific
to Result itself, but I believe that the false positive rate for the
unused_result lint is too high to make it useful when turned on by default.
2014-01-28 15:54:47 -08:00
Niko Matsakis
afd8df6af2 Add test case for #3243, which was fixed as part of fix for #3511.
(Lifetime of stack allocated vectors was not being enforced)

Closes #3243.
2014-01-28 16:53:50 -05:00
bors
1ac9bf65b6 auto merge of #11738 : dmanescu/rust/11721, r=alexcrichton
Fixes #11721
2014-01-27 21:46:33 -08:00
bors
d21b18306c auto merge of #11826 : huonw/rust/7621-deriving-errors, r=alexcrichton
cc #7621.

See the commit message. I'm not sure if we should merge this now, or wait until we can write `Clone::clone(x)` which will directly solve the above issue with perfect error messages.
2014-01-27 20:26:35 -08:00
Nick Desaulniers
ea9db66c50 can borrow mut in proc Fixes #10617 2014-01-27 17:06:11 -08:00
Huon Wilson
cb02a37042 syntax: make deriving have slightly less cryptic error messages.
This unfortunately changes an error like

    error: mismatched types: expected `&&NotClone` but found `&NotClone`

into

    error: type `NotClone` does not implement any method in scope named `clone`
2014-01-28 11:07:45 +11:00
bors
d6d7812da8 auto merge of #11595 : eddyb/rust/env-et-self-no-more, r=nikomatsakis
Non-exhaustive change list:
* `self` is now present in argument lists (modulo type-checking code I don't trust myself to refactor)
* methods have the same calling convention as bare functions (including the self argument)
* the env param is gone from all bare functions (and methods), only used by closures and `proc`s
* bare functions can only be coerced to closures and `proc`s if they are statically resolved, as they now require creating a wrapper specific to that function, to avoid indirect wrappers (equivalent to `impl<..Args, Ret> Fn<..Args, Ret> for fn(..Args) -> Ret`) that might not be optimizable by LLVM and don't work for `proc`s
* refactored some `trans::closure` code, leading to the removal of `trans::glue::make_free_glue` and `ty_opaque_closure_ptr`
2014-01-27 09:31:44 -08:00
David Manescu
28b987b99a Feature gate #[simd]
Fixes #11721
2014-01-28 01:04:15 +11:00
xales
b23fd080ff Feature gate trace_macros.
Fixes #11631
2014-01-27 09:02:22 -05:00
Eduard Burtescu
15ba0c310a Demote self to an (almost) regular argument and remove the env param.
Fixes #10667 and closes #10259.
2014-01-27 14:31:24 +02:00
bors
b0280ac538 auto merge of #11834 : huonw/rust/deriving-spans, r=alexcrichton
I'd forgotten to update them when I changed this a while ago; it now displays error messages linked to the struct/variant field, rather than the `#[deriving(Trait)]` line, for all traits.

This also adds a very large number of autogenerated tests. I can easily remove/tone down that commit if necessary.
2014-01-27 01:21:31 -08:00
Huon Wilson
d9a204bf4c Add autogenerated tests for the spans of various derived traits. 2014-01-27 15:28:04 +11:00
bors
d3f70f5a7d auto merge of #11817 : salemtalha/rust/master, r=brson
Fixes Issue #11815
2014-01-26 15:26:30 -08:00
Salem Talha
cc61fc0994 Removed all instances of XXX in preparation for relaxing of FIXME rule 2014-01-26 14:42:53 -05:00
Alex Crichton
4d6836f418 Fix privacy fallout from previous change 2014-01-26 11:03:13 -08:00
Alex Crichton
31ac9c4288 Change private structs to have private fields by default
This was the original intention of the privacy of structs, and it was
erroneously implemented before. A pub struct will now have default-pub fields,
and a non-pub struct will have default-priv fields. This essentially brings
struct fields in line with enum variants in terms of inheriting visibility.

As usual, extraneous modifiers to visibility are disallowed depend on the case
that you're dealing with.

Closes #11522
2014-01-26 10:37:08 -08:00
Steven Fackler
86a8b031f5 Move macro_rules! macros to libstd
They all have to go into a single module at the moment unfortunately.
Ideally, the logging macros would live in std::logging, condition! would
live in std::condition, format! in std::fmt, etc. However, this
introduces cyclic dependencies between those modules and the macros they
use which the current expansion system can't deal with. We may be able
to get around this by changing the expansion phase to a two-pass system
but that's for a later PR.

Closes #2247
cc #11763
2014-01-24 08:35:39 -08:00
Kiet Tran
b3290d322e Make some borrow checker errors more user friendly
A mutable and immutable borrow place some restrictions on what you can
with the variable until the borrow ends. This commit attempts to convey
to the user what those restrictions are. Also, if the original borrow is
a mutable borrow, the error message has been changed (more specifically,
i. "cannot borrow `x` as immutable because it is also borrowed as
mutable" and ii. "cannot borrow `x` as mutable more than once" have
been changed to "cannot borrow `x` because it is already borrowed as
mutable").

In addition, this adds a (custom) span note to communicate where the
original borrow ends.
2014-01-23 14:44:28 -05:00
Huon Wilson
3901228811 rustc: add lint for parens in if, while, match and return.
The parens in `if (true) {}` are not not necessary, so we'll warn about
them.
2014-01-21 21:58:48 +11:00
bors
02d4572696 auto merge of #11661 : huonw/rust/fixed-length-instantiation, r=thestinger
Previously, they were treated like ~[] and &[] (which can have length
0), but fixed length vectors are fixed length, i.e. we know at compile
time if it's possible to have length zero (which is only for [T, .. 0]).

Fixes #11659.
2014-01-20 06:16:29 -08:00
bors
e594acad5f auto merge of #11656 : brson/rust/omgandroid, r=cmr 2014-01-20 01:11:35 -08:00
bors
7c33df0dbb auto merge of #11644 : huonw/rust/less-fatality, r=cmr
This means that compilation continues for longer, and so we can see more
errors per compile. This is mildly more user-friendly because it stops
users having to run rustc n times to see n macro errors: just run it
once to see all of them.
2014-01-19 16:56:40 -08:00
bors
6d58c70fb3 auto merge of #11628 : alexcrichton/rust/issue-11593, r=brson
Turns out we were just forgetting to encode the privacy for trais, and
everything without privacy defaults to public!

Closes #11593
2014-01-19 00:36:48 -08:00
Huon Wilson
6f3c202d3e rustc: check instantiability of fixed length vectors properly.
Previously, they were treated like ~[] and &[] (which can have length
0), but fixed length vectors are fixed length, i.e. we know at compile
time if it's possible to have length zero (which is only for [T, .. 0]).

Fixes #11659.
2014-01-19 18:48:20 +11:00
bors
c0578b4a41 auto merge of #11632 : brson/rust/issue-11602, r=huonw 2014-01-18 16:46:39 -08:00
Brian Anderson
2ff5963b9d xfail more external syntax extension tests on android 2014-01-18 16:32:33 -08:00
bors
b5a110c7fe auto merge of #11607 : alexcrichton/rust/issue-9957, r=cmr
For `use` statements, this means disallowing qualifiers when in functions and
disallowing `priv` outside of functions.

For `extern mod` statements, this means disallowing everything everywhere. It
may have been envisioned for `pub extern mod foo` to be a thing, but it
currently doesn't do anything (resolve doesn't pick it up), so better to err on
the side of forwards-compatibility and forbid it entirely for now.

Closes #9957
2014-01-18 13:01:47 -08:00
Alex Crichton
d37e2f79cc Disallow implementation of cross-crate priv traits
Turns out we were just forgetting to encode the privacy for trais, and
everything without privacy defaults to public!

Closes #11593
2014-01-18 10:58:01 -08:00
Alex Crichton
4a78364d49 Forbid unnecessary visibility on view items
For `use` statements, this means disallowing qualifiers when in functions and
disallowing `priv` outside of functions.

For `extern mod` statements, this means disallowing everything everywhere. It
may have been envisioned for `pub extern mod foo` to be a thing, but it
currently doesn't do anything (resolve doesn't pick it up), so better to err on
the side of forwards-compatibility and forbid it entirely for now.

Closes #9957
2014-01-18 10:46:32 -08:00
bors
88dd987df0 auto merge of #11605 : alexcrichton/rust/issue-9582, r=brson
Closes #9582
2014-01-18 01:06:47 -08:00
Brian Anderson
f52bd5e4b7 rustc: Feature gate log_syntax!. Closes #11602 2014-01-17 20:10:47 -08:00