| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
where possible.
|
|
|
|
|
|
Conflicts:
src/libcollections/slice.rs
src/libcollections/str.rs
src/librustc/middle/lang_items.rs
src/librustc_back/rpath.rs
src/librustc_typeck/check/regionck.rs
src/libstd/ffi/os_str.rs
src/libsyntax/diagnostic.rs
src/libsyntax/parse/parser.rs
src/libsyntax/util/interner.rs
src/test/run-pass/regions-refcell.rs
|
|
|
|
support warnings.
|
|
Conflicts:
src/librustc_trans/trans/tvec.rs
|
|
they are used without a feature-gate. This is both kinder to existing
code and should make it easier to land this PR, since we don't
have to catch EVERY SINGLE SUFFIX.
|
|
|
|
|
|
|
|
It's not clear what this means, because a macro in item position can expand to zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect, which seems quite unintended.
Fixes #18317.
Fixes #14660.
|
|
Some function signatures have changed, so this is a [breaking-change].
In particular, radixes and numerical values of digits are represented by `u32` now.
Part of #22240
|
|
|
|
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes #22137
|
|
It's not clear what this means, because a macro in item position can expand to
zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect,
which seems quite unintended.
Fixes #18317.
Fixes #14660.
|
|
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes #22137
|
|
Conflicts:
src/test/compile-fail/reserved-be.rs
src/test/compile-fail/reserved-become.rs
src/test/parse-fail/reserved-be.rs
|
|
Closes #20022
|
|
It's in order to make the code more homogeneous.
|
|
Fixes run build error
Fix test failure
Fix tests' errors
|
|
The word is repeated twice in the message like:
error: obsolete syntax: `:`, `&mut:`, or `&:` syntax
This removes the word syntax that appears in messages after the second colon (:).
|
|
The word is repeated twice in the message like
error: obsolete syntax: `:`, `&mut:`, or `&:` syntax
This removes the word syntax that appears in messages after the second colon (:).
|
|
|
|
|
|
|
|
|
|
|
|
The spelling corrections were made in both documentation comments and
regular comments.
|
|
This can be considered partial work on #8256.
The main observable change: macro expansion sometimes results in spans where `lo > hi`; so for now, when we have such a span, do not attempt to return a snippet result.
(Longer term, we might think about whether we could still present a snippet for the cases where this arises, e.g. perhaps by showing the whole macro as the snippet, assuming that is the sole cause of such spans; or by somehow looking up the closest AST node that holds both `lo` and `hi`, and showing that.)
As a drive-by, revised the API to return a `Result` rather than an `Option`, with better information-packed error value that should help us (and maybe also our users) identify the causes of such problems in the future. Ideally the call-sites that really want an actual snippet would be updated to catch the newly added `Err` case and print something meaningful about it, but that is not part of this PR.
|
|
Implement step 1 of rust-lang/rfcs#702
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
|
|
This can be considered partial work on #8256.
The main observable change: macro expansion sometimes results in spans
where `lo > hi`; so for now, when we have such a span, do not attempt
to return a snippet result.
(Longer term, we might think about whether we could still present a
snippet for the cases where this arises, e.g. perhaps by showing the
whole macro as the snippet, assuming that is the sole cause of such
spans; or by somehow looking up the closest AST node that holds both
`lo` and `hi`, and showing that.)
As a drive-by, revised the API to return a `Result` rather than an
`Option`, with better information-packed error value that should help
us (and maybe also our users) identify the causes of such problems in
the future. Ideally the call-sites that really want an actual snippet
would be updated to catch the newly added `Err` case and print
something meaningful about it, but that is not part of this PR.
|
|
|
|
The spelling corrections were made in both documentation comments and
regular comments.
|
|
|
|
|
|
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
|
|
This *almost* completes the job for #16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done.
As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.)
This commit does not *quite* fix #16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends.
r? @eddyb as he reviewed the prior patch in this direction
|
|
As per rust-lang/rfcs#601, replace `be` with `become` as reserved
keyword for tail call optimization.
|
|
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this
commit renames `std::path` to `std::old_path`, leaving the existing path
API in place to ease migration to the new one. Updating should be as
simple as adjusting imports, and the prelude still maps to the old path
APIs for now.
[breaking-change]
|
|
|
|
upgrade the inference based on expected type so that it is able to
infer the fn kind in isolation even if the full signature is not
available (and we could perhaps do better still in some cases, such as
extracting just the types of the arguments but not the return value).
|
|
syntax like `use foo::bar::;` and `use foo:: as bar;` should be rejected, see issue #21629
|
|
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes #21839
[breaking-change]
|
|
Conflicts:
src/librustc/metadata/filesearch.rs
src/librustc_back/target/mod.rs
src/libstd/os.rs
src/libstd/sys/windows/os.rs
src/libsyntax/ext/tt/macro_parser.rs
src/libsyntax/print/pprust.rs
src/test/compile-fail/issue-2149.rs
|
|
|
|
Conflicts:
src/libsyntax/parse/parser.rs
|
|
Also `for x in option.into_iter()` -> `if let Some(x) = option`
|
|
|
