Resolves third bullet of #4691: if the functional-struct-update (FSU) expression `{ a: b, ..s }` causes `s` to move and `s` has a destructor, then the expression is illegal.
r? @nikomatsakis
This is for consistency in naming conventions.
- ``std::num::Float::NaN()`` is changed to ``nan()``;
- ``std::num::Float.is_NaN()`` is changed to ``is_nan()``; and
- ``std::num::strconv::NumStrConv::NaN()`` is changed to ``nan()``.
Fixes#9319.
This is the second of two parts of #8991, now possible as a new snapshot
has been made. (The first part implemented the unreachable!() macro; it
was #8992, 6b7b8f2682.)
``std::util::unreachable()`` is removed summarily; any code which used
it should now use the ``unreachable!()`` macro.
Closes#9312.
Closes#8991.
Previously, the lexer calling `rdr.fatal(...)` would report the span of
the last complete token, instead of a span within the erroneous token
(besides one span fixed in 1ac90bb).
This branch adds wrappers around `rdr.fatal(...)` that sets the span
explicilty, so that all fatal errors in `libsyntax/parse/lexer.rs` now
report the offending code more precisely. A number of tests try to
verify that, though the `compile-fail` testing setup can only check that
the spans are on the right lines, and the "unterminated string/block
comment" errors can't have the line marked at all, so that's incomplete.
This closes#9149.
Also, the lexer errors now report the offending code in the error message,
not just via the span, just like other errors do.
The `Drop` implementation was used to prevent `Future` from being implicitly copyable. Since `~fn`s are no longer copyable, this is no longer needed. I added a cfail test to make sure that this is actually the case.
I method-ized all of the `Future` creation methods and added a new one, `spawn_with`, which is similar to `task::spawn_with`.
I also got rid of some unused imports in tests.
Previously, the lexer calling `rdr.fatal(...)` would report the span of
the last complete token, instead of a span within the erroneous token
(besides one span fixed in 1ac90bb).
This commit adds a wrapper around `rdr.fatal(...)` that sets the span
explicilty, so that all fatal errors in `libsyntax/parse/lexer.rs` now
report the offending code more precisely. A number of tests try to
verify that, though the `compile-fail` testing setup can only check that
the spans are on the right lines, and the "unterminated string/block
comment" errors can't have the line marked at all, so that's incomplete.
Closes#9149.
This is for consistency in naming conventions.
- ``std::num::Float::NaN()`` is changed to ``nan()``;
- ``std::num::Float.is_NaN()`` is changed to ``is_nan()``; and
- ``std::num::strconv::NumStrConv::NaN()`` is changed to ``nan()``.
Fixes#9319.
This is the second of two parts of #8991, now possible as a new snapshot
has been made. (The first part implemented the unreachable!() macro; it
was #8992, 6b7b8f2682.)
``std::util::unreachable()`` is removed summarily; any code which used
it should now use the ``unreachable!()`` macro.
Closes#9312.
Closes#8991.
This renames the syntax-extension file to format from ifmt, and it also reduces
the amount of complexity inside by defining all other macros in terms of
format_args!
The purpose of this macro is to further reduce the number of allocations which
occur when dealing with formatting strings. This macro will perform all of the
static analysis necessary to validate that a format string is safe, and then it
will wrap up the "format string" into an opaque struct which can then be passed
around.
Two safe functions are added (write/format) which take this opaque argument
structure, unwrap it, and then call the unsafe version of write/format (in an
unsafe block). Other than these two functions, it is not intended for anyone to
ever look inside this opaque struct.
The macro looks a bit odd, but mostly because of rvalue lifetimes this is the
only way for it to be safe that I know of.
Example use-cases of this are:
* third-party libraries can use the default formatting syntax without any
forced allocations
* the fail!() macro can avoid allocating the format string
* the logging macros can avoid allocation any strings
This removes another large chunk of this odd 'clownshoes' identifier showing up
in symbol names. These all originated from external crates because the encoded
items were encoded independently of the paths calculated in ast_map. The
encoding of these paths now uses the helper function in ast_map to calculate the
"pretty name" for an impl block.
Unfortunately there is still no information about generics in the symbol name,
but it's certainly vastly better than before
hash::__extensions__::write::_version::v0.8
becomes
hash::Writer$SipState::write::hversion::v0.8
This also fixes bugs in which lots of methods would show up as `meth_XXX`, they
now only show up as `meth` and throw some extra characters onto the version
string.
These commits fix bugs related to identically named statics in functions of implementations in various situations. The commit messages have most of the information about what bugs are being fixed and why.
As a bonus, while I was messing around with name mangling, I improved the backtraces we'll get in gdb by removing `__extensions__` for the trait/type being implemented and by adding the method name as well. Yay!
Remove __extensions__ from method symbols as well as the meth_XXX. The XXX is
now used to append a few characters at the end of the name of the symbol.
Closes#6602
This is currently unsound since `bool` is represented as `i8`. It will
become sound when `bool` is stored as `i8` but always used as `i1`.
However, the current behaviour will always be identical to `x & 1 != 0`,
so there's no need for it. It's also surprising, since `x != 0` is the
expected behaviour.
Closes#7311
Current access methods are nestable and unsafe. This patch renames
current methods implementation - prepends unsafe_ - and implements 2 new
methods that are both safe and un-nestable.
Fixes#7473
There are 6 new compiler recognised attributes: deprecated, experimental,
unstable, stable, frozen, locked (these levels are taken directly from
Node's "stability index"[1]). These indicate the stability of the
item to which they are attached; e.g. `#[deprecated] fn foo() { .. }`
says that `foo` is deprecated.
This comes with 3 lints for the first 3 levels (with matching names) that
will detect the use of items marked with them (the `unstable` lint
includes items with no stability attribute). The attributes can be given
a short text note that will be displayed by the lint. An example:
#[warn(unstable)]; // `allow` by default
#[deprecated="use `bar`"]
fn foo() { }
#[stable]
fn bar() { }
fn baz() { }
fn main() {
foo(); // "warning: use of deprecated item: use `bar`"
bar(); // all fine
baz(); // "warning: use of unmarked item"
}
The lints currently only check the "edges" of the AST: i.e. functions,
methods[2], structs and enum variants. Any stability attributes on modules,
enums, traits and impls are not checked.
[1]: http://nodejs.org/api/documentation.html
[2]: the method check is currently incorrect and doesn't work.
I've added a test for the second example mentioned in #5239. The first example does not compile with a reasonable error message. Should I add a compile-fail test for that example as well?
/rust/src/test/run-pass/issue-5239.rs:15:45: 15:51 error: binary operation + cannot be applied to type `&int`
rust/src/test/run-pass/issue-5239.rs:15 let _f = |ref x: int| { x += 1};
^~~~~~
error: aborting due to previous error
This removes the stacking of type parameters that occurs when invoking
trait methods, and fixes all places in the standard library that were
relying on it. It is somewhat awkward in places; I think we'll probably
want something like the `Foo::<for T>::new()` syntax.
Fixes for #8625 to prevent assigning to `&mut` in borrowed or aliasable locations. The old code was insufficient in that it failed to catch bizarre cases like `& &mut &mut`.
r? @pnkfelix
This is a pull request for #2275
I've created a small python script to generate test files for a list of keywords (as break do else enum extern false fn for if impl let loop match mod mut priv pub ref return self static struct super true trait type unsafe use while), but I'm not really sure where to put it. I've added the created files as well.
I did not use
fn main() {
let $KW = "foo"; //~ error
println($KW); //~ error
}
as template, because for return, self, ref, loop, mut and break this does not raise an error in the ```println``` line, only in the ```let``` line.
For #7083.
The metadata issue with the old version is now fixed. Ready for review.
This is also not the full solution to #7083, because this is not supported yet:
```
trait Foo : Send { }
impl <T: Send> Foo for T { }
fn foo<T: Foo>(val: T, chan: std::comm::Chan<T>) {
chan.send(val);
}
```
cc @nikomatsakis
When using a `do` block to call an internal iterator, if you forgot to
return a value from the body, it would tell you
error: Do-block body must return bool, but returns () here. Perhaps
you meant to write a `for`-loop?
This advice no longer applies as `for` loops are now for external
iterators. Delete this message outright and let it use the default error
message
error: mismatched types: expected `bool` but found `()`
r? @thestinger
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.
Fixes#6610.
When using a `do` block to call an internal iterator, if you forgot to
return a value from the body, it would tell you
error: Do-block body must return bool, but returns () here. Perhaps
you meant to write a `for`-loop?
This advice no longer applies as `for` loops are now for external
iterators. Delete this message outright and let it use the default error
message
error: mismatched types: expected `bool` but found `()`
This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that *have* to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that have to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.
Fixes#6610.
Fix#3192. r? anyone
There are 4 different new tests, to check some different scenarios for
what the parse context is at the time of recovery, becasue our
compile-fail infrastructure does not appear to handle verifying
error-recovery situations.
Differentiate between unit-like struct definition item and unit-like
struct construction in the error message.
----
More generally, outlines a more generic strategy for parse error
recovery: By committing to an expression/statement at set points in
the parser, we can then do some look-ahead to catch common mistakes
and skip over them.
One detail about this strategy is that you want to avoid emitting the
"helpful" message unless the input is reasonably close to the case of
interest. (E.g. do not warn about a potential unit struct for an
input of the form `let hmm = do foo { } { };`)
To accomplish this, I added (partial) last_token tracking; used for
`commit_stmt` support.
The check_for_erroneous_unit_struct_expecting fn returns bool to
signal whether it "made progress"; currently unused; this is meant for
use to compose several such recovery checks together in a loop.
This PR fixes#7235 and #3371, which removes trailing nulls from `str` types. Instead, it replaces the creation of c strings with a new type, `std::c_str::CString`, which wraps a malloced byte array, and respects:
* No interior nulls
* Ends with a trailing null
There are 4 different new tests, to check some different scenarios for
what the parse context is at the time of recovery, becasue our
compile-fail infrastructure does not appear to handle verifying
error-recovery situations.
Differentiate between unit-like struct definition item and unit-like
struct construction in the error message.
----
More generally, outlines a more generic strategy for parse error
recovery: By committing to an expression/statement at set points in
the parser, we can then do some look-ahead to catch common mistakes
and skip over them.
One detail about this strategy is that you want to avoid emitting the
"helpful" message unless the input is reasonably close to the case of
interest. (E.g. do not warn about a potential unit struct for an
input of the form `let hmm = do foo { } { };`)
To accomplish this, I added (partial) last_token tracking; used for
`commit_stmt` support.
The check_for_erroneous_unit_struct_expecting fn returns bool to
signal whether it "made progress"; currently unused; this is meant for
use to compose several such recovery checks together in a loop.
env! aborts compilation of the specified environment variable is not
defined and takes an optional second argument containing a custom
error message. option_env! creates an Option<&'static str> containing
the value of the environment variable.
There are no run-pass tests that check the behavior when the environment
variable is defined since the test framework doesn't support setting
environment variables at compile time as opposed to runtime. However,
both env! and option_env! are used inside of rustc itself, which should
act as a sufficient test.
Fixes#2248.
This is a fairly large rollup, but I've tested everything locally, and none of
it should be platform-specific.
r=alexcrichton (bdfdbdd)
r=brson (d803c18)
r=alexcrichton (a5041d0)
r=bstrie (317412a)
r=alexcrichton (135c85e)
r=thestinger (8805baa)
r=pcwalton (0661178)
r=cmr (9397fe0)
r=cmr (caa4135)
r=cmr (6a21d93)
r=cmr (4dc3379)
r=cmr (0aa5154)
r=cmr (18be261)
r=thestinger (f10be03)
env! aborts compilation of the specified environment variable is not
defined and takes an optional second argument containing a custom
error message. option_env! creates an Option<&'static str> containing
the value of the environment variable.
There are no run-pass tests that check the behavior when the environment
variable is defined since the test framework doesn't support setting
environment variables at compile time as opposed to runtime. However,
both env! and option_env! are used inside of rustc itself, which should
act as a sufficient test.
Close#2248
Code like this is fixed now:
```
fn foo(p: [u8, ..4]) {
match p {
[a, b, c, d] => {}
};
}
```
Invalid constructors are not reported as errors yet:
```
fn foo(p: [u8, ..4]) {
match p {
[_, _, _] => {} // this should be error
[_, _, _, _, _, .._] => {} // and this
_ => {}
}
}
```
Issue #8311 is partially fixed by this commit. Fixed-length arrays in
let statement are not yet allowed:
```
let [a, b, c] = [1, 2, 3]; // still fails
```
- Made naming schemes consistent between Option, Result and Either
- Changed Options Add implementation to work like the maybe monad (return None if any of the inputs is None)
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead
This is preparation for removing `@fn`.
This does *not* use default methods yet, because I don't know
whether they work. If they do, a forthcoming PR will use them.
This also changes the precedence of `as`.
Change the former repetition::
for 5.times { }
to::
do 5.times { }
.times() cannot be broken with `break` or `return` anymore; for those
cases, use a numerical range loop instead.
To be more specific:
`UPPERCASETYPE` was changed to `UppercaseType`
`type_new` was changed to `Type::new`
`type_function(value)` was changed to `value.method()`
Hi,
As noted in #6804, a pattern that contains `NaN` will never match because `NaN != NaN`. This adds a warning for such a case. The first commit handles the basic case and the second one generalizes it to more complex patterns using `walk_pat`.
`crate => Crate`
`local => Local`
`blk => Block`
`crate_num => CrateNum`
`crate_cfg => CrateConfig`
Also, Crate and Local are not wrapped in spanned<T> anymore.
If the TLS key is 0-sized, then the linux linker is apparently smart enough to
put everything at the same pointer. OSX on the other hand, will reserve some
space for all of them. To get around this, the TLS key now actuall consumes
space to ensure that it gets a unique pointer
Rust will allow to supply default methods for all four methods, but we
don't have any nice error reporting for the case where at least one
method must be implemented, but it's arbitrary which.
So in this case, we require `lt`, but allow implementing the others if needed.
It will be simpler to implement only one method for Ord, while we also
allow implementing all four Ord methods for semantics or performance
reasons.
We only supply three default methods (and not four), because don't have
any nice error reporting for the case where at least one method must be
implemented, but it's arbitrary which.
cc #6004 and #3273
This is a rewrite of TLS to get towards not requiring `@` when using task local storage. Most of the rewrite is straightforward, although there are two caveats:
1. Changing `local_set` to not require `@` is blocked on #7673
2. The code in `local_pop` is some of the most unsafe code I've written. A second set of eyes should definitely scrutinize it...
The public-facing interface currently hasn't changed, although it will have to change because `local_data::get` cannot return `Option<T>`, nor can it return `Option<&T>` (the lifetime isn't known). This will have to be changed to be given a closure which yield `&T` (or as an Option). I didn't do this part of the api rewrite in this pull request as I figured that it could wait until when `@` is fully removed.
This also doesn't deal with the issue of using something other than functions as keys, but I'm looking into using static slices (as mentioned in the issues).
This a followup to #7510. @catamorphism requested a test - so I have created one, but in doing so I noticed some inconsistency in the error messages resulting from referencing nonexistent traits, so I changed the messages to be more consistent.
Adds a lint for `static some_lowercase_name: uint = 1;`. Warning by default since it causes confusion, e.g. `static a: uint = 1; ... let a = 2;` => `error: only refutable patterns allowed here`.
common supertypes.
This was breaking with the change to regions because of the
(now incorrect) assumpton that our inference code makes,
which is that if a <: b succeeds, there is no need to compute
the LUB/GLB.
This patch makes error handling for region inference failures more
uniform by not reporting *any* region errors until the reigon inference
step. This requires threading through more information about what
caused a region constraint, so that we can still give informative
error messages.
I have only taken partial advantage of this information: when region
inference fails, we still report the same error we always did, despite
the fact that we now know precisely what caused the various constriants
and what the region variable represents, which we did not know before.
This change is required not only to improve error messages but
because the region hierarchy is not in fact fully known until regionck,
because it is not clear where closure bodies fit in (our current
treatment is unsound). Moreover, the relationships between free variables
cannot be fully determined until type inference is otherwise complete.
cc #3238.
The commit f9a5453 is meant to be a temporary hold-over. Whether or not there is added a way for the compiler to "implicitly borrow" stack closures in this way, there should be a codegen optimization that prevents having to traverse possibly-very-many function pointers to find the function you ultimately wanted to call. I tried to separate out the changes so this particular commit could be straight-up reverted if auto-borrowing happens in the future.
r? @nikomatsakis
@graydon suggested that once closures not be part of the language for 1.0, but that they might be hidden behind a -Z compile flag as an "experimental feature" in case people decide they need them.
Regardless of whether ```-Z once-fns``` is set, this PR will parse the ```once``` keyword and will prevent closures labelled with it from being called more than once. It will also permit moving out of captured vars in heap closures, just to let the runtime writers stop using ```Cell``` sooner. Setting ```-Z once-fns``` only toggles whether the move-out-from-capture privilege is also given for stack closures.
r? @nikomatsakis
Fix#7322.
I started out with a band-aid approach to special-case the duplicate module error using `is_duplicate_module`, but thought this would be better in the long term.
add_child() is responsible for reporting errors about type, value, and
module duplicate definitions. Although it checks for all three, it uses
namespace_to_str() to convert a Namespace value into a string before
printing an error like:
error: duplicate definition of type `foo`
^^^^
note: first definition of type foo here:
^^^^
Unfortunately, this string can only be one of "type" or
"value" (corresponding to TypeNS and ValueNS respectively), and it
reports duplicate modules as duplicate types.
To alleviate the problem, define a special NamespaceError enum to define
more specialized errors, and use it instead of attempting to reuse the
Namespace enum.
Reported-by: Corey Richardson <corey@octayn.net>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
I removed the `static-method-test.rs` test because it was heavily based
on `BaseIter` and there are plenty of other more complex uses of static
methods anyway.
Minimally fixes#7017, we were overwriting the result and thus ignoring attributes before the last.
csearch::get_item_attrs and decoder::get_item_attrs should probably also be changed to each_item_attrs using the for protocol, but that's just a minor performance/style issue.
There are two distinct kinds of bad-for-loops to check for with two
distinct error messages. The current bad-for-loop.rs does not make this
clear, so rewrite it into bad-for-loop{,-2}.rs. The two failing
prototypes are:
fn quux(_: &fn(&int) -> int) -> bool { true }
fn quux(_: &fn(&int) -> bool) -> () { }
Note that the second one runs fine in rust-0.6 (the latest release), and
only fails with a rust built from `incoming`.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Closes#5090 by using the excellent new generic deriving code
Promotes the unreachable code attribute to a lint attribute (instead of always being a warning)
Fixes some edge cases when creating hashmaps/hashsets and also when consuming them. (fixes#5998)
borrow checker and generalize what moves are allowed. Fixes a nasty
bug or two in the pattern move checking code. Unifies dataflow code
used for initialization and other things. First step towards
once fns. Everybody wins.
Fixes#4384. Fixes#4715. cc once fns (#2202), optimizing local moves (#5016).
This adds a lint mode for detecting unnecessary allocations on the heap. This isn't super fancy, currently it only has two rules
1. For a function's arguments, if you allocate a `[~|@]str` literal, when the type of the argument is a `&str`, emit a warning.
2. For the same case, emit warnings for boxed vectors when slices are required.
After adding the lint, I rampaged through the libraries and removed all the unnecessary allocations I could find.
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual auto_* code, leaving stubs to refer the user to
the new syntax.
Also, moves the useful contents of auto_encode.rs to more appropriate spots: tests and comments to deriving/encodable.rs, and the ExtCtxtMethods trait to build.rs (unused so far, but the method syntax might be nicer than using the mk_* fns in many instances).
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual code, leaving stubs to refer the user to
the new syntax.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
r? @pcwalton
* Move `SharedMutableState`, `LittleLock`, and `Exclusive` from `core::unstable` to `core::unstable::sync`
* Modernize the `SharedMutableState` interface with methods
* Rename `SharedMutableState` to `UnsafeAtomicRcBox` to match `RcBox`.
Every unresolved import is reported. An additional error message isn't useful
and obscures (imo) the real errors: I need to take it into account when
looking at the error count.
r? @nikomatsakis In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).
Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).
Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
**Caveat**: With the current commit, this check only works for `match`s, the checks (incorrectly) do not run for patterns in `let`s, and invalid/unsafe code compiles.
I don't know how to fix this, I experimented with some things to try to make let patterns and match patterns run on the same code (since this would presumably fix many of the other unsoundness issues of let-patterns, e.g. #6225), but I don't understand enough of the code. (I think I heard someone talking about a fix for `let` being in progress?)
Fixes#6344 and #6341.
Closes#6183.
The first commit changes the compiler's method of treating a `for` loop, and all the remaining commits are just dealing with the fallout.
The biggest fallout was the `IterBytes` trait, although it's really a whole lot nicer now because all of the `iter_bytes_XX` methods are just and-ed together. Sadly there was a huge amount of stuff that's `cfg(stage0)` gated, but whoever lands the next snapshot is going to have a lot of fun deleting all this code!
&str can be turned into @~str on demand, using to_owned(), so for
strings, we can create a specialized interner that accepts &str for
intern() and find() but stores and returns @~str.
This improves error reporting for the following class of imports:
```rust
use foo::bar;
```
Where foo, the topmost module, is unresolved. It now results in:
```text
/tmp/foo.rs:1:4: 1:7 error: unresolved import. perhapsyou forgot an 'extern mod foo'?
/tmp/foo.rs:1 use foo::bar;
^~~
/tmp/foo.rs:1:4: 1:12 error: failed to resolve import: foo::bar
/tmp/foo.rs:1 use foo::bar;
^~~~~~~~
error: failed to resolve imports
error: aborting due to 3 previous errors
```
This is the first of a series of changes I plan on making to unresolved name error messages.
Use a bitset to represent built-in bounds. There are several places in the language where only builtin bounds (aka kinds) will be accepted, e.g. on closures, destructor type parameters perhaps, and on trait types.
r? @brson
