| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It's more helpful to list the span of each open delimiter seen so far
than to print out an error with the span of the last position in the file.
Closes #2354
|
|
A few features are now hidden behind various #[feature(...)] directives. These
include struct-like enum variants, glob imports, and macro_rules! invocations.
Closes #9304
Closes #9305
Closes #9306
Closes #9331
|
|
This PR solves one of the pain points with c-style enums. Simplifies writing a fn to convert from an int/uint to an enum. It does this through a `#[deriving(FromPrimitive)]` syntax extension.
Before this is committed though, we need to discuss if `ToPrimitive`/`FromPrimitive` has the right design (cc #4819). I've changed all the `.to_int()` and `from_int()` style functions to return `Option<int>` so we can handle partial functions. For this PR though only enums and `extra::num::bigint::*` take advantage of returning None for unrepresentable values. In the long run it'd be better if `i64.to_i8()` returned `None` if the value was too large, but I'll save this for a future PR.
Closes #3868.
|
|
Replaces existing tests for removed obsolete-syntax errors with tests
for the resulting regular errors, adds a test for each of the removed
parser errors to make sure that obsolete forms don't start working
again, removes some obsolete/superfluous tests that were now failing.
Deletes some amount of dead code in the parser, also includes some small
changes to parser error messages to accomodate new tests.
|
|
This purges about 500 lines of visitor cruft from lint passes. All lints are
handled in a much more sane way at this point. The other huge bonus of this
commit is that there are no more @-boxes in the lint passes, fixing the 500MB
memory regression seen when the lint passes were refactored.
Closes #8589
|
|
One downside with this current implementation is that since BigInt's
default is now 64 bit, we can convert larger BigInt's to a primitive,
however the current implementation on 32 bit architectures does not
take advantage of this fact.
|
|
|
|
Right now this only works for c-style enums.
|
|
That is, only a single expression or item gets parsed, so if there are
any extra tokens (e.g. the start of another item/expression) the user
should be told, rather than silently dropping them.
An example:
macro_rules! foo {
() => {
println("hi");
println("bye);
}
}
would expand to just `println("hi")`, which is almost certainly not
what the programmer wanted.
Fixes #8012.
|
|
Uses the new snapshots to kill the old `loop` and introduce the new `continue`.
|
|
That is, only a single expression or item gets parsed, so if there are
any extra tokens (e.g. the start of another item/expression) the user
should be told, rather than silently dropping them.
An example:
macro_rules! foo {
() => {
println("hi");
println("bye);
}
}
would expand to just `println("hi")`, which is almost certainly not
what the programmer wanted.
Fixes #8012.
|
|
|
|
Closes #9467
|
|
|
|
r? @thestinger
|
|
|
|
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes #6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
|
|
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes #6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
|
|
Closes #9631
|
|
|
|
This lets them get past the non_uppercase_statics lint mode (if it's turned on)
Closes #9631
|
|
|
|
|
|
We're not outright removing fmt! just yet, but this prevents it from leaking
into the compiler further (it's still turned on by default for all other code).
|
|
Closes #9621
|
|
|
|
|
|
As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.
This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).
Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.
|
|
As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.
This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).
Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.
|
|
The 0.8 release was cut, down with printf!
|
|
Commit messages have the details, mostly just knocking out more low-hanging-fruit type issues.
|
|
|
|
|
|
|
|
This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.
|
|
|
|
These are deprecated in favor of print{,ln}!
|
|
|
|
Closes #8965
|
|
This slurps up everything inside of an 'extern' block into the enclosing module
in order to document them. The documentation must be on the items themselves,
and they'll show up next to everything else on the module index pages.
Closes #5953
|
|
Fixes #9348.
|
|
|
|
|
|
This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.
|
|
There is less implicit removal of various comment styles, and it also removes
extraneous stars occasionally found in docblock comments. It turns out that the
bug for getops was just a differently formatted block.
Closes #9425
Closes #9417
|
|
find src -name '*.rs' | xargs sed -i '' 's/~~~.*{\.rust}/```rust/g'
find src -name '*.rs' | xargs sed -i '' 's/ ~~~$/ ```/g'
find src -name '*.rs' | xargs sed -i '' 's/^~~~$/ ```/g'
|
|
Small stuff... might as well get it into the tree. One new test case, some issue # cleanup, remove some unused imports.
|
|
This fixes private statics and functions from being usable cross-crates, along
with some bad privacy error messages. This is a reopening of #8365 with all the
privacy checks in privacy.rs instead of resolve.rs (where they should be
anyway).
These maps of exported items will hopefully get used for generating
documentation by rustdoc
Closes #8592
|
|
As documented in issue #7945, these literal identifiers are all accepted by rust
today, but they should probably be disallowed (especially `'''`). This changes
all escapable sequences to being *required* to be escaped.
Closes #7945
I wanted to write the tests with more exact spans, but I think #9308 will be fixing that?
|
|
As documented in issue #7945, these literal identifiers are all accepted by rust
today, but they should probably be disallowed (especially `'''`). This changes
all escapable sequences to being *required* to be escaped.
Closes #7945
|
