| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This breaks code that looks like this:
trait Foo {
extern "C" unsafe fn foo();
}
impl Foo for Bar {
extern "C" unsafe fn foo() { ... }
}
Change such code to look like this:
trait Foo {
unsafe extern "C" fn foo();
}
impl Foo for Bar {
unsafe extern "C" fn foo() { ... }
}
Fixes #19398.
[breaking-change]
|
|
with a full stop
|
|
No semantic changes, no enabling `if let` where it wasn't already enabled.
|
|
|
|
|
|
Sister pull request of https://github.com/rust-lang/rust/pull/19288, but
for the other style of block doc comment.
|
|
Implements RFC 438.
Fixes #19092.
This is a [breaking-change]: change types like `&Foo+Send` or `&'a mut Foo+'a` to `&(Foo+Send)` and `&'a mut (Foo+'a)`, respectively.
r? @brson
|
|
This is considered good convention.
This is about half of them in total, I just don't want an impossible to land patch. :smile:
|
|
appropriately.
|
|
This is considered good convention.
|
|
|
|
This commit removes the `std::local_data` module in favor of a new
`std::thread_local` module providing thread local storage. The module provides
two variants of TLS: one which owns its contents and one which is based on
scoped references. Each implementation has pros and cons listed in the
documentation.
Both flavors have accessors through a function called `with` which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of [RFC 461][rfc] and full details can be found in
that RFC.
This is a breaking change due to the removal of the `std::local_data` module.
All users can migrate to the new thread local system like so:
thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None)))
The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as
an implementation detail which must now be explicitly stated by users.
[rfc]: https://github.com/rust-lang/rfcs/pull/461
[breaking-change]
|
|
|
|
This breaks code like
```
let t = (42i, 42i);
... t.0::<int> ...;
```
Change this code to not contain an unused type parameter. For example:
```
let t = (42i, 42i);
... t.0 ...;
```
Closes https://github.com/rust-lang/rust/issues/19096
[breaking-change]
|
|
|
|
Free functions deprecated. UnicodeChar experimental pending
final decisions about prelude.
|
|
[breaking-change]
|
|
|
|
r=acrichto
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.
|
|
optional unboxed closure kind.
|
|
This moves errors and all handling of numeric suffixes into the parser
rather than the lexer.
|
|
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.
|
|
|
|
|
|
Allows parsing view items (`use` and `extern crate`) individually. Does not change behavior of any existing functions.
Closes #19024
|
|
`Box<for<'a> Foo<&'a T> + 'a>` can be accepted. Also cleanup the visitor/fold
in general, exposing more callbacks.
|
|
|
|
|
|
Came up on IRC that this was a bit unhelpful as to what should actually be *done*. I am new to changing compiler messages, please let me know if there's anything else that needs to be done to accomadate this change.
(My build system is still constantly crashing [Is bors contagious?], so this hasn't been formally `check`ed. I figure it's a simple enough change that any consequences [like compile-fail expected messages?] can be eyeballed by someone more experienced.)
|
|
Make struct variant syntax more consistent with struct syntax and fix an
assert in middle::typeck.
Fix #19003
|
|
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]
|
|
|
|
Make struct variant syntax more consistent with struct syntax and fix an
assert in middle::typeck.
Fix #19003
|
|
Struct variant field visibility is now inherited. Remove `pub` keywords
from declarations.
Closes #18641
[breaking-change]
r? @alexcrichton
|
|
[breaking-change]
This will break any uses of macros that assumed () being a valid literal.
|
|
Struct variant field visibility is now inherited. Remove `pub` keywords
from declarations.
Closes #18641
[breaking-change]
|
|
Fix some old papercuts with diagnostics, e.g. tweaking spans, rewording messages. See individual commits.
|
|
This implements a considerable portion of rust-lang/rfcs#369 (tracked in #18640). Some interpretations had to be made in order to get this to work. The breaking changes are listed below:
[breaking-change]
- `core::num::{Num, Unsigned, Primitive}` have been deprecated and their re-exports removed from the `{std, core}::prelude`.
- `core::num::{Zero, One, Bounded}` have been deprecated. Use the static methods on `core::num::{Float, Int}` instead. There is no equivalent to `Zero::is_zero`. Use `(==)` with `{Float, Int}::zero` instead.
- `Signed::abs_sub` has been moved to `std::num::FloatMath`, and is no longer implemented for signed integers.
- `core::num::Signed` has been removed, and its methods have been moved to `core::num::Float` and a new trait, `core::num::SignedInt`. The methods now take the `self` parameter by value.
- `core::num::{Saturating, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv}` have been removed, and their methods moved to `core::num::Int`. Their parameters are now taken by value. This means that
- `std::time::Duration` no longer implements `core::num::{Zero, CheckedAdd, CheckedSub}` instead defining the required methods non-polymorphically.
- `core::num::{zero, one, abs, signum}` have been deprecated. Use their respective methods instead.
- The `core::num::{next_power_of_two, is_power_of_two, checked_next_power_of_two}` functions have been deprecated in favor of methods defined a new trait, `core::num::UnsignedInt`
- `core::iter::{AdditiveIterator, MultiplicativeIterator}` are now only implemented for the built-in numeric types.
- `core::iter::{range, range_inclusive, range_step, range_step_inclusive}` now require `core::num::Int` to be implemented for the type they a re parametrized over.
|
|
This corrects the error message to point at the literal, not the next
token.
Closes #17123.
|
|
Adds a method for printing a fatal error and also a help message to the
parser and uses this in a variety of places to improve error messages.
Closes #12213.
|
|
This can crop-up with a misconfigured editor or an unexpected
interaction between version control and certain operating systems.
Closes #11669.
|
|
Num, NumCast, Unsigned, Float, Primitive and Int have been removed.
|
|
|
|
This breaks code like:
struct Foo {
x: int,
}
let f: Foo = ...;
... f.x::<int> ...
Change this code to not contain an unused type parameter. For example:
struct Foo {
x: int,
}
let f: Foo = ...;
... f.x ...
Closes #18680.
[breaking-change]
|
|
|
|
|
|
|
|
Closes #14197
Removes the `matchers` nonterminal.
If you're using `$foo:matchers` in a macro, write `$foo:tt` instead.
[breaking-change]
|
|
|
