| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Allows modifiers to be used on methods, associated types, etc.
r? @sfackler
|
|
|
|
Allows modifiers to be used on methods, associated types, etc.
|
|
Conflicts:
src/libflate/lib.rs
src/libstd/lib.rs
src/libstd/macros.rs
src/libsyntax/feature_gate.rs
src/libsyntax/parse/parser.rs
src/libsyntax/show_span.rs
src/test/auxiliary/macro_crate_test.rs
src/test/compile-fail/lint-stability.rs
src/test/run-pass/intrinsics-math.rs
src/test/run-pass/tcp-connect-timeouts.rs
|
|
Conflicts:
src/librustc_typeck/check/_match.rs
|
|
|
|
|
|
Instead of copy-pasting the whole macro_rules! item from the original .rs file,
we serialize a separate name, attributes list, and body, the latter as
pretty-printed TTs. The compilation of macro_rules! macros is decoupled
somewhat from the expansion of macros in item position.
This filters out comments, and facilitates selective imports.
|
|
This implements RFC 179 by making the pattern `&<pat>` require matching
against a variable of type `&T`, and introducing the pattern `&mut
<pat>` which only works with variables of type `&mut T`.
The pattern `&mut x` currently parses as `&(mut x)` i.e. a pattern match
through a `&T` or a `&mut T` that binds the variable `x` to have type
`T` and to be mutable. This should be rewritten as follows, for example,
for &mut x in slice.iter() {
becomes
for &x in slice.iter() {
let mut x = x;
Due to this, this is a
[breaking-change]
Closes #20496.
|
|
This commit introduces the syntax for negative implmenetations of traits
as shown below:
`impl !Trait for Type {}`
cc #13231
Part of RFC #3
|
|
Conflicts:
src/librustc/middle/traits/mod.rs
src/libstd/io/mod.rs
src/test/run-pass/builtin-superkinds-self-type.rs
|
|
|
|
|
|
Part of #19607.
r? @nikomatsakis
|
|
[breaking-change]
The `mut` in slices is now redundant. Mutability is 'inferred' from position. This means that if mutability is only obvious from the type, you will need to use explicit calls to the slicing methods.
|
|
Note that this doesn't add the surface syntax.
|
|
(on platforms with 64-bit pointers.)
The StmtMac variant is rather large and also fairly rare, so let's
optimise the common case.
|
|
Includes a bit of refactoring to store `?` unbounds as bounds with a modifier, rather than in their own world, in the AST at least.
|
|
|
|
|
|
Implement support in the parser for generalized where clauses,
as well as the conversion of ast::WherePredicates to
ty::Predicate in `collect.rs`.
|
|
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes #18635.
[breaking-change]
|
|
This is to allow us to migrate away from UnUniq in a followup commit,
and thus unify the code paths related to all forms of `box`.
|
|
results.
|
|
integrating into rustdoc etc.
|
|
|
|
language. Recommend `move||` instead.
|
|
|
|
|
|
bounds.
|
|
|
|
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.
|
|
optional unboxed closure kind.
|
|
|
|
`Box<for<'a> Foo<&'a T> + 'a>` can be accepted. Also cleanup the visitor/fold
in general, exposing more callbacks.
|
|
[breaking-change]
This will break any uses of macros that assumed () being a valid literal.
|
|
Various miscellaneous changes pushing towards HRTB support:
1. Update parser and adjust ast to support `for<'a,'b>` syntax, both in closures and trait bounds. Warn on the old syntax (not error, for stage0).
2. Refactor TyTrait representation to include a TraitRef.
3. Purge `once_fns` feature gate and `once` keyword.
r? @pcwalton
This is a [breaking-change]:
- The `once_fns` feature is now officially deprecated. Rewrite using normal closures or unboxed closures.
- The new `for`-based syntax now issues warnings (but not yet errors):
- `fn<'a>(T) -> U` becomes `for<'a> fn(T) -> U`
- `<'a> |T| -> U` becomes `for<'a> |T| -> U`
|
|
This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.
This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.
cc #18585
|
|
|
|
This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.
This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.
cc #18585
|
|
Closes #14197
Removes the `matchers` nonterminal.
If you're using `$foo:matchers` in a macro, write `$foo:tt` instead.
[breaking-change]
|
|
|
|
completely.
|
|
These paths also bind anonymous regions (or will, once HRTB is fully working).
Fixes #18423.
|
|
|
|
|
|
bounds like any other "type parameter".
|
|
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]
|
