Use the expected type to infer the argument/return types of unboxed closures. Also, in `||` expressions, use the expected type to decide if the result should be a boxed or unboxed closure (and if an unboxed closure, what kind).
This supercedes PR #19089, which was already reviewed by @pcwalton.
Futureproof Rust for fancier suffixed literals. The Rust compiler tokenises a literal followed immediately (no whitespace) by an identifier as a single token: (for example) the text sequences `"foo"bar`, `1baz` and `1u1024` are now a single token rather than the pairs `"foo"` `bar`, `1` `baz` and `1u` `1024` respectively.
The compiler rejects all such suffixes in the parser, except for the 12 numeric suffixes we have now.
I'm fairly sure this will affect very few programs, since it's not currently legal to have `<literal><identifier>` in a Rust program, except in a macro invocation. Any macro invocation relying on this behaviour can simply separate the two tokens with whitespace: `foo!("bar"baz)` becomes `foo!("bar" baz)`.
This implements [RFC 463](https://github.com/rust-lang/rfcs/blob/master/text/0463-future-proof-literal-suffixes.md), and so closes https://github.com/rust-lang/rust/issues/19088.
This adds an optional suffix at the end of a literal token:
`"foo"bar`. An actual use of a suffix in a expression (or other literal
that the compiler reads) is rejected in the parser.
This doesn't switch the handling of numbers to this system, and doesn't
outlaw illegal suffixes for them yet.
The trait has an obvious, sensible implementation directly on vectors so
the MemWriter wrapper is unnecessary. This will halt the trend towards
providing all of the vector methods on MemWriter along with eliminating
the noise caused by conversions between the two types. It also provides
the useful default Writer methods on Vec<u8>.
After the type is removed and code has been migrated, it would make
sense to add a new implementation of MemWriter with seeking support. The
simple use cases can be covered with vectors alone, and ones with the
need for seeks can use a new MemWriter implementation.
`slice_shift_char` splits a `str` into it's leading `char` and the remainder of the `str`. Currently, it returns a `(Option<char>, &str)` such that:
"bar".slice_shift_char() => (Some('b'), "ar")
"ar".slice_shift_char() => (Some('a'), "r")
"r".slice_shift_char() => (Some('r'), "")
"".slice_shift_char() => (None, "")
This is a little odd. Either a `str` can be split into both a head and a tail or it cannot. So the return type should be `Option<(char, &str)>`. With the current behaviour, in the case of the empty string, the `str` returned is meaningless - it is always the empty string.
This PR changes `slice_shift_char` so that:
"bar".slice_shift_char() => Some(('b', "ar"))
"ar".slice_shift_char() => Some(('a', "r"))
"r".slice_shift_char() => Some(('r', ""))
"".slice_shift_char() => None
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
`slice_shift_char` splits a `str` into it's leading `char` and the remainder
of the `str`. Currently, it returns a `(Option<char>, &str)` such that:
"bar".slice_shift_char() => (Some('b'), "ar")
"ar".slice_shift_char() => (Some('a'), "r")
"r".slice_shift_char() => (Some('r'), "")
"".slice_shift_char() => (None, "")
This is a little odd. Either a `str` can be split into both a head and a
tail or it cannot. So the return type should be `Option<(char, &str)>`.
With the current behaviour, in the case of the empty string, the `str`
returned is meaningless - it is always the empty string.
This commit changes slice_shift_char so that:
"bar".slice_shift_char() => Some(('b', "ar"))
"ar".slice_shift_char() => Some(('a', "r"))
"r".slice_shift_char() => Some(('r', ""))
"".slice_shift_char() => None
[breaking-change]
Unicode characters and strings.
Use `\u0080`-`\u00ff` instead. ASCII/byte literals are unaffected.
This PR introduces a new function, `escape_default`, into the ASCII
module. This was necessary for the pretty printer to continue to
function.
RFC #326.
Closes#18062.
[breaking-change]
This commit enables implementations of IndexMut for a number of collections,
including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same
time this deprecates the `get_mut` methods on vectors in favor of using the
indexing notation.
cc #18424
This common representation for delimeters should make pattern matching easier. Having a separate `token::DelimToken` enum also allows us to enforce the invariant that the opening and closing delimiters must be the same in `ast::TtDelimited`, removing the need to ensure matched delimiters when working with token trees.
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]
Use the `is_shorthand` field introduced by #17813 (ead6c4b) to make the
prettyprinter output the shorthand form. Fixes a few places that set
`is_shorthand: true` when the pattern is not a PatIdent with the same
name as the field.
This should be clearer, and fits in better with the `TTNonterminal` variant.
Renames:
- `TTTok` -> `TTToken`
- `TTDelim` -> `TTDelimited`
- `TTSeq` -> `TTSequence`
This came up when working [on the gl-rs generator extension](990383de80/src/gl_generator/lib.rs (L135-L146)).
The new definition of `TTDelim` adds an associated `Span` that covers the whole token tree and enforces the invariant that a delimited sequence of token trees must have an opening and closing delimiter.
A `get_span` method has also been added to `TokenTree` type to make it easier to implement better error messages for syntax extensions.
This is a large spring-cleaning commit now that the 0.12.0 release has passed removing an amount of deprecated functionality. This removes a number of deprecated crates (all still available as cargo packages in the rust-lang organization) as well as a slew of deprecated functions. All `#[crate_id]` support has also been removed.
I tried to avoid anything that was recently deprecated, but I may have missed something! The major pain points of this commit is the fact that rustc/syntax have `#[allow(deprecated)]`, but I've removed that annotation so moving forward they should be cleaned up as we go.
Spring cleaning is here! In the Fall! This commit removes quite a large amount
of deprecated functionality from the standard libraries. I tried to ensure that
only old deprecated functionality was removed.
This is removing lots and lots of deprecated features, so this is a breaking
change. Please consult the deprecation messages of the deleted code to see how
to migrate code forward if it still needs migration.
[breaking-change]
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
[rfc]: https://github.com/rust-lang/rfcs/pull/246
Modify ast::ExprMatch to include a new value of type ast::MatchSource,
making it easy to tell whether the match was written literally or
produced via desugaring. This allows us to customize error messages
appropriately.
in favor of `move`.
This breaks code that used `move` as an identifier, because it is now a
keyword. Change such identifiers to not use the keyword `move`.
Additionally, this breaks code that was counting on by-value or
by-reference capture semantics for unboxed closures (behind the feature
gate). Change `ref |:|` to `|:|` and `|:|` to `move |:|`.
Part of RFC #63; part of issue #12831.
[breaking-change]
Change to resolve and update compiler and libs for uses.
[breaking-change]
Enum variants are now in both the value and type namespaces. This means that
if you have a variant with the same name as a type in scope in a module, you
will get a name clash and thus an error. The solution is to either rename the
type or the variant.
Part of issue #16640. I am leaving this issue open to handle parsing of
higher-rank lifetimes in traits.
This change breaks code that used unboxed closures:
* Instead of `F:|&: int| -> int`, write `F:Fn(int) -> int`.
* Instead of `F:|&mut: int| -> int`, write `F:FnMut(int) -> int`.
* Instead of `F:|: int| -> int`, write `F:FnOnce(int) -> int`.
[breaking-change]
The implementation essentially desugars during type collection and AST
type conversion time into the parameter scheme we have now. Only fully
qualified names--e.g. `<T as Foo>::Bar`--are supported.
This allows code to access the fields of tuples and tuple structs:
let x = (1i, 2i);
assert_eq!(x.1, 2);
struct Point(int, int);
let origin = Point(0, 0);
assert_eq!(origin.0, 0);
assert_eq!(origin.1, 0);
instead of prefix `..`.
This breaks code that looked like:
match foo {
[ first, ..middle, last ] => { ... }
}
Change this code to:
match foo {
[ first, middle.., last ] => { ... }
}
RFC #55.
Closes#16967.
[breaking-change]
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).
E.g.
```rust
#![feature(macro_rules)]
// minimal junk
#![no_std]
macro_rules! foo {
($x: ident) => { y + $x }
}
fn bar() {
foo!(x)
}
```
```rust
#![feature(macro_rules)]
// minimal junk
#![no_std]
fn bar /* 61#0 */() { y /* 60#2 */ + x /* 58#3 */ }
```
`--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).
For review. Not sure about the link_attrs stuff. Will work on converting all the tests.
extern crate "foobar" as foo;
extern crate foobar as foo;
Implements remaining part of RFC #47.
Addresses issue #16461.
Removed link_attrs from rust.md, they don't appear to be supported by
the parser.
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
Implements remaining part of RFC #47.
Addresses issue #16461.
Removed link_attrs from rust.md, they don't appear to be supported by
the parser.
Changed all the tests to use the new extern crate syntax
Change pretty printer to use 'as' syntax
Stop read+write expressions from expanding into two occurences
in the AST. Add a bool to indicate whether an operand in output
position if read+write or not.
Fixes#14936
These `where` clauses are accepted everywhere generics are currently
accepted and desugar during type collection to the type parameter bounds
we have today.
A new keyword, `where`, has been added. Therefore, this is a breaking
change. Change uses of `where` to other identifiers.
[breaking-change]
r? @nikomatsakis (or whoever)
These `where` clauses are accepted everywhere generics are currently
accepted and desugar during type collection to the type parameter bounds
we have today.
A new keyword, `where`, has been added. Therefore, this is a breaking
change. Change uses of `where` to other identifiers.
[breaking-change]
methods.
This paves the way to associated items by introducing an extra level of
abstraction ("impl-or-trait item") between traits/implementations and
methods. This new abstraction is encoded in the metadata and used
throughout the compiler where appropriate.
There are no functional changes; this is purely a refactoring.
This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.
This breaks code that looked like:
let mut f;
{
let x = &5i;
f = |&mut:| *x + 10;
}
Change this code to avoid having a reference escape. For example:
{
let x = &5i;
let mut f; // <-- move here to avoid dangling reference
f = |&mut:| *x + 10;
}
I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.
Closes#14449.
[breaking-change]
by-reference upvars.
This partially implements RFC 38. A snapshot will be needed to turn this
on, because stage0 cannot yet parse the keyword.
Part of #12831.
r? @alexcrichton
by-reference upvars.
This partially implements RFC 38. A snapshot will be needed to turn this
on, because stage0 cannot yet parse the keyword.
Part of #12381.
This adds support to `quote_expr!` and friends for round-trip hygienic
preservation of Ident.
Here are the pieces of the puzzle:
* adding a method for encoding Ident for re-reading into token tree.
* Support for reading such encoded Idents in the lexer. Note that one
must peek ahead for MOD_SEP after scan_embedded_hygienic_ident.
* To ensure that encoded Idents are only read when we are in the midst
of expanding a `quote_expr` or similar, added a
`read_embedded_ident` flag on `StringReader`.
* pprust support for encoding Ident's as (uint,uint) pairs (for hygiene).
meaning `'b outlives 'a`. Syntax currently does nothing but is needed for full
fix to #5763. To use this syntax, the issue_5763_bootstrap feature guard is
required.
The `type_overflow` lint, doesn't catch the overflow for `i64` because
the overflow happens earlier in the parse phase when the `u64` as biggest
possible int gets casted to `i64` , without checking the for overflows.
We can't lint in the parse phase, so a refactoring of the `LitInt` type
was necessary.
The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one
type `LitInt` which stores it's value as `u64`. An additional parameter was
added which indicate the signedness of the type and the sign of the value.
This eliminates the last vestige of the `~` syntax.
Instead of `~self`, write `self: Box<TypeOfSelf>`; instead of `mut
~self`, write `mut self: Box<TypeOfSelf>`, replacing `TypeOfSelf` with
the self-type parameter as specified in the implementation.
Closes#13885.
[breaking-change]
except where trait objects are involved.
Part of issue #15349, though I'm leaving it open for trait objects.
Cross borrowing for trait objects remains because it is needed until we
have DST.
This will break code like:
fn foo(x: &int) { ... }
let a = box 3i;
foo(a);
Change this code to:
fn foo(x: &int) { ... }
let a = box 3i;
foo(&*a);
[breaking-change]
This makes two changes to region inference: (1) it allows region
inference to relate early-bound regions; and (2) it allows regions to be
related before variance runs. The former is needed because there is no
relation between the two regions before region substitution happens,
while the latter is needed because type collection has to run before
variance. We assume that, before variance is inferred, that lifetimes
are invariant. This is a conservative overapproximation.
This relates to #13885. This does not remove `~self` from the language
yet, however.
[breaking-change]
This change propagates to many locations, but because of the
Macro Exterminator (or, more properly, the invariant that it
protects), macro invocations can't occur downstream of expansion.
This means that in librustc and librustdoc, extracting the
desired field can simply assume that it can't be a macro
invocation. Functions in ast_util abstract over this check.
formerly, the self identifier was being discarded during parsing, which
stymies hygiene. The best fix here seems to be to attach a self identifier
to ExplicitSelf_, a change that rippled through the rest of the compiler,
but without any obvious damage.
This updates https://github.com/rust-lang/rust/pull/15075.
Rename `ToStr::to_str` to `ToString::to_string`. The naive renaming ends up with two `to_string` functions defined on strings in the prelude (the other defined via `collections::str::StrAllocating`). To remedy this I removed `StrAllocating::to_string`, making all conversions from `&str` to `String` go through `Show`. This has a measurable impact on the speed of this conversion, but the sense I get from others is that it's best to go ahead and unify `to_string` and address performance for all `to_string` conversions in `core::fmt`. `String::from_str(...)` still works as a manual fast-path.
Note that the patch was done with a script, and ended up renaming a number of other `*_to_str` functions, particularly inside of rustc. All the ones I saw looked correct, and I didn't notice any additional API breakage.
Closes#15046.
closes#13367
[breaking-change] Use `Sized?` to indicate a dynamically sized type parameter or trait (used to be `type`). E.g.,
```
trait Tr for Sized? {}
fn foo<Sized? X: Share>(x: X) {}
```
Rationale: for what appear to be historical reasons only, the PatIdent contains
a Path rather than an Ident. This means that there are many places in the code
where an ident is artificially promoted to a path, and---much more problematically---
a bunch of elements from a path are simply thrown away, which seems like an invitation
to some really nasty bugs.
This commit replaces the Path in a PatIdent with a SpannedIdent, which just contains an ident
and a span.
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
RFC #27.
After a snapshot, the old syntax will be removed.
This can break some code that looked like `foo as &Trait:Send`. Now you
will need to write `foo as (&Trait+Send)`.
Closes#12778.
[breaking-change]
the leading quote part of the identifier for the purposes of hygiene.
This adopts @jbclements' solution to #14539.
I'm not sure if this is a breaking change or not.
Closes#12512.
[breaking-change]
This uncovered some dead code, most notably in middle/liveness.rs, which I think suggests there must be something fishy with that part of the code.
The #[allow(dead_code)] annotations on some of the fields I am not super happy about but as I understand, marker type may disappear at some point.
This makes ast::Arg usable in the quote_ macros.
Please note that this commit doesn't include a regression test. There
are tests that use the quote macros, but all of them are ignored. Due to
that, there is no obvious (to me) way to test this.
Since this change is absolutely trivial and only hooks up an additional
type to existing infrastructure (which presumably is tested elsewhere),
I concluded it's not worth the effort to follow up on this.
This is part of the ongoing renaming of the equality traits. See #12517 for more
details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord}
or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}.
cc #12517
[breaking-change]
When printing doc comments, always put a newline after them in a macro
invocation to ensure that a line-doc-comment doesn't consume remaining tokens on
the line.
Integers are always parsed as a u64 in libsyntax, but they're stored as i64. The
parser and pretty printer both printed an i64 instead of u64, sometimes
introducing an extra negative sign.
* Added `// no-pretty-expanded` to pretty-print a test, but not run it through
the `expanded` variant.
* Removed #[deriving] and other expanded attributes after they are expanded
* Removed hacks around &str and &&str and friends (from both the parser and the
pretty printer).
* Un-ignored a bunch of tests
Some `Expr` needs parentheses when printed. For example, without
parentheses, `ExprUnary(UnNeg, ExprBinary(BiAdd, ..))` becomes
`-lhs + rhs` which is wrong.
Those cases don't appear in ordinary code (since parentheses are
explicitly added) but they can appear in manually crafted ast by
extensions.
This commit revisits the `cast` module in libcore and libstd, and scrutinizes
all functions inside of it. The result was to remove the `cast` module entirely,
folding all functionality into the `mem` module. Specifically, this is the fate
of each function in the `cast` module.
* transmute - This function was moved to `mem`, but it is now marked as
#[unstable]. This is due to planned changes to the `transmute`
function and how it can be invoked (see the #[unstable] comment).
For more information, see RFC 5 and #12898
* transmute_copy - This function was moved to `mem`, with clarification that is
is not an error to invoke it with T/U that are different
sizes, but rather that it is strongly discouraged. This
function is now #[stable]
* forget - This function was moved to `mem` and marked #[stable]
* bump_box_refcount - This function was removed due to the deprecation of
managed boxes as well as its questionable utility.
* transmute_mut - This function was previously deprecated, and removed as part
of this commit.
* transmute_mut_unsafe - This function doesn't serve much of a purpose when it
can be achieved with an `as` in safe code, so it was
removed.
* transmute_lifetime - This function was removed because it is likely a strong
indication that code is incorrect in the first place.
* transmute_mut_lifetime - This function was removed for the same reasons as
`transmute_lifetime`
* copy_lifetime - This function was moved to `mem`, but it is marked
`#[unstable]` now due to the likelihood of being removed in
the future if it is found to not be very useful.
* copy_mut_lifetime - This function was also moved to `mem`, but had the same
treatment as `copy_lifetime`.
* copy_lifetime_vec - This function was removed because it is not used today,
and its existence is not necessary with DST
(copy_lifetime will suffice).
In summary, the cast module was stripped down to these functions, and then the
functions were moved to the `mem` module.
transmute - #[unstable]
transmute_copy - #[stable]
forget - #[stable]
copy_lifetime - #[unstable]
copy_mut_lifetime - #[unstable]
[breaking-change]
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes#10025
[breaking-change]
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
How to update your code:
* Instead of `~EXPR`, you should write `box EXPR`.
* Instead of `~TYPE`, you should write `Box<Type>`.
* Instead of `~PATTERN`, you should write `box PATTERN`.
[breaking-change]
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes#10025
[breaking-change]
Clearly storing them as `char` is semantically nicer, but this also
fixes a bug whereby `quote_expr!(cx, 'a')` wasn't working, because the
code created by quotation was not matching the actual AST definitions.
it reflected the obsolete syntax `use a, b, c;` and did not make
past the parser (though it was a non-fatal error so we can continue).
this legacy affected many portions of rustc and rustdoc as well,
so this commit cleans them up altogether.
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Closes#9390Closes#13684Closes#13709
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Closes#9390Closes#13684Closes#13709
This removes the `priv` keyword from the language and removes private enum
variants as a result. The remaining use cases of private enum variants were all
updated to be a struct with one private field that is a private enum.
RFC: 0006-remove-priv
Closes#13535
libstd: Implement `StrBuf`, a new string buffer type like `Vec`, and port all code over to use it.
Rebased & tests-fixed version of https://github.com/mozilla/rust/pull/13269
In summary these are some example transitions this change makes:
'a || => ||: 'a
proc:Send() => proc():Send
The intended syntax for closures is to put the lifetime bound not at the front
but rather in the list of bounds. Currently there is no official support in the
AST for bounds that are not 'static, so this case is currently specially handled
in the parser to desugar to what the AST is expecting. Additionally, this moves
the bounds on procedures to the correct position, which is after the argument
list.
The current grammar for closures and procedures is:
procedure := 'proc' [ '<' lifetime-list '>' ] '(' arg-list ')'
[ ':' bound-list ] [ '->' type ]
closure := [ 'unsafe' ] ['<' lifetime-list '>' ] '|' arg-list '|'
[ ':' bound-list ] [ '->' type ]
lifetime-list := lifetime | lifetime ',' lifetime-list
arg-list := ident ':' type | ident ':' type ',' arg-list
bound-list := bound | bound '+' bound-list
bound := path | lifetime
This does not currently handle the << ambiguity in `Option<<'a>||>`, I am
deferring that to a later patch. Additionally, this removes the support for the
obsolete syntaxes of ~fn and &fn.
Closes#10553Closes#10767Closes#11209Closes#11210Closes#11211
This change removes the AbiSet from the AST, converting all usage to have just
one Abi value. The current scheme selects a relevant ABI given a list of ABIs
based on the target architecture and how relevant each ABI is to that
architecture.
Instead of this mildly complicated scheme, only one ABI will be allowed in abi
strings, and pseudo-abis will be created for special cases as necessary. For
example the "system" abi exists for stdcall on win32 and C on win64.
Closes#10049
The previous syntax was `Foo:Bound<trait-parameters>`, but this is a little
ambiguous because it was being parsed as `Foo: (Bound<trait-parameters)` rather
than `Foo: (Bound) <trait-parameters>`
This commit changes the syntax to `Foo<trait-parameters>: Bound` in order to be
clear where the trait parameters are going.
Closes#9265
The previous syntax was `Foo:Bound<trait-parameters>`, but this is a little
ambiguous because it was being parsed as `Foo: (Bound<trait-parameters)` rather
than `Foo: (Bound) <trait-parameters>`
This commit changes the syntax to `Foo<trait-parameters>: Bound` in order to be
clear where the trait parameters are going.
Closes#9265
This change is in preparation for #8122. Nothing is currently done with these
visibility qualifiers, they are just parsed and accepted by the compiler.
RFC: 0004-private-fields
The pretty printer constitues an enormous amount of code, there's no reason for
it to be generic. This just least to a huge amount of metadata which isn't
necessary. Instead, this change migrates the pretty printer to using a trait
object instead.
Closes#12985
This commit removes all internal support for the previously used __log_level()
expression. The logging subsystem was previously modified to not rely on this
magical expression. This also removes the only other function to use the
module_data map in trans, decl_gc_metadata. It appears that this is an ancient
function from a GC only used long ago.
This does not remove the crate map entirely, as libgreen still uses it to hook
in to the event loop provided by libgreen.
Previously `ast::Arm` was always storing a single `ast::Expr` wrapped in an
`ast::Block` (for historical reasons, AIUI), so we might as just store
that expr directly.
Closes#3085.
