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.
of tracking individual candidates per impl, we just track one
candidate for the extension trait itself, and let the trait resolution
handle walking the individual impls and so forth. Also change the
interface to report back a richer notion of error.
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 adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.
They look like this:
```
match.rs:10:13: 10:14 error: unreachable pattern [E0001]
match.rs:10 1 => {},
^
match.rs:3:1: 3:38 note: in expansion of foo!
match.rs:7:5: 20:2 note: expansion site
match.rs:10:13: 10:14 help: pass `--explain E0001` to see a detailed explanation
```
(`help` is coloured cyan.) Adding these errors on a separate line stops the lines from being too long, as discussed in #16619.
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
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]
Closes#17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
Instead of returning &'static [u8], an invocation of `bytes!()` now returns
`&'static [u8, ..N]` where `N` is the length of the byte vector. This should
functionally be the same, but there are some cases where an explicit cast may be
needed, so this is a:
[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
For example, this matcher: `fn $name:ident( $($param:ident : $pty:ty),* )` would fail when parsing `fn foo()`, because macro parser wouldn't realize that an ident cannot start with `)`.
This resolves#5902, and at least partially mitigates #9364 and #3232.
This rewrites them to the current `ItemStatic` production of the compiler, but I
want to get this into a snapshot. It will be illegal to use a `static` in a
pattern of a `match` statement, so all those current uses will need to be
rewritten to `const` once it's implemented. This requires that the stage0
snapshot is able to parse `const`.
cc #17718
prefer `Deref` over `DerefMut` in all other circumstances.
Because the compiler now prefers `Deref`, this can break code that
looked like:
let mut foo = bar.borrow_mut();
(*foo).call_something_that_requires_mutable_self();
Replace this code with:
let mut foo = bar.baz();
(&mut *foo).call_something_that_requires_mutable_self();
Closes#12825.
[breaking-change]
r? @nikomatsakis
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.
This makes it easier to experiment with improved quasiquoting as an ordinary
plugin library.
The list of quote macros in feature_gate.rs was already out of sync;
this commit also prevents that problem in the future.
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]
Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
but this still needs to be done on the rest of the maps. However they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree` is part of the complete rewrite in #17334.
The implemented API deviates from the API described in the RFC in two key places:
* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.
This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.
[breaking-change]
This extends cfg-gating to attributes.
```rust
#[cfg_attr(<cfg pattern>, <attr>)]
```
will expand to
```rust
#[<attr>]
```
if the `<cfg pattern>` matches the current cfg environment, and nothing
if it does not. The grammar for the cfg pattern has a simple
recursive structure:
* `value` and `key = "value"` are cfg patterns,
* `not(<cfg pattern>)` is a cfg pattern and matches if `<cfg pattern>`
does not.
* `all(<cfg pattern>, ...)` is a cfg pattern and matches if all of the
`<cfg pattern>`s do.
* `any(<cfg pattern>, ...)` is a cfg pattern and matches if any of the
`<cfg pattern>`s do.
Examples:
```rust
// only derive Show for assert_eq! in tests
#[cfg_attr(test, deriving(Show))]
struct Foo { ... }
// only derive Show for assert_eq! in tests and debug builds
#[cfg_attr(any(test, not(ndebug)), deriving(Show))]
struct Foo { ... }
// ignore a test in certain cases
#[test]
#[cfg_attr(all(not(target_os = "linux"), target_endian = "big"), ignore)]
fn test_broken_thing() { ... }
// Avoid duplication when fixing staging issues in rustc
#[cfg_attr(not(stage0), lang="iter")]
pub trait Iterator<T> { ... }
```
Because I'm still 😷😷😷 , I figured some mindless tasks would be better than trying to finish the ownership guide.
The manual has long been waiting for some ❤️❤️❤️ , and so I gave it a quick once-over. I made small commits in case any of the changes are a bit weird, I mostly did a few things:
1. changed 'manual' to 'reference.' I feel like this name is better. If it's not, It's not a huge deal. it shouldn't be `rust.md` though.
2. word wrapped everything appropriately. Changes 1&2 are in the first commit, so that its' easier to see the changes in the later ones.
3. fixed other small style issues
4. removed references to things that are in the standard library, and not the language itself
There's still lots of gross in here, but I didn't want to pile on too too many changes.
/cc @brson @nikomatsakis
This breaks code like:
struct Foo {
...
}
pub fn make_foo() -> Foo {
...
}
Change this code to:
pub struct Foo { // note `pub`
...
}
pub fn make_foo() -> Foo {
...
}
The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API. In its place
a `#[feature(visible_private_types)]` gate has been added.
Closes#16463.
RFC #48.
[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]
This breaks code that looked like:
mymacro!(static::foo);
... where `mymacro!` expects a path or expression. Change such macros to
not accept keywords followed by `::`.
Closes#17298.
[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 prevents confusing errors when accidentally using an assignment
in an `if` expression. For example:
```rust
fn main() {
let x = 1u;
if x = x {
println!("{}", x);
}
}
```
Previously, this yielded:
```
test.rs:4:16: 4:17 error: expected `:`, found `!`
test.rs:4 println!("{}", x);
^
```
With this change, it now yields:
```
test.rs:3:8: 3:13 error: mismatched types: expected `bool`, found `()` (expected bool, found ())
test.rs:3 if x = x {
^~~~~
```
Closes issue #17283
The `StrInterner::clear()` method takes self immutably but can invalidate references returned by `StrInterner::get_ref`. Since `get_ref` is unused, just remove it.
Closes#17181
Sized deallocation makes it pointless to provide an address that never
overlaps with pointers returned by an allocator. Code can branch on the
capacity of the allocation instead of a comparison with this sentinel.
This improves the situation in #8859, and the remaining issues are only
from the logging API, which should be disabled by default in optimized
release builds anyway along with debug assertions. The remaining issues
are part of #17081.
Closes#8859
This adds ‘help’ diagnostic messages to rustc. This is used for anything that
provides help to the user, particularly the `--explain` messages that were
previously integrated into the relevant error message.
type they provide an implementation for.
This breaks code like:
mod foo {
struct Foo { ... }
}
impl foo::Foo {
...
}
Change this code to:
mod foo {
struct Foo { ... }
impl Foo {
...
}
}
Additionally, if you used the I/O path extension methods `stat`,
`lstat`, `exists`, `is_file`, or `is_dir`, note that these methods have
been moved to the the `std::io::fs::PathExtensions` trait. This breaks
code like:
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Change this code to:
use std::io::fs::PathExtensions;
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Closes#17059.
RFC #155.
[breaking-change]
The other extension types already worked this way and it can be useful to track some state along with the extension.
I also removed the `BasicMacroExpander` and `BasicIdentMacroExpander` since the span inside of them was never used. The expander function types now directly implement the relevant trait.
The string slices returned by `get_ref` can actually be
invalidated by calling `clear`. Since this method is unused,
it is easiest to simply remove it.
Closes#17181
This PR creates a new lint : ``unused_extern_crate``, which do pretty much the same thing as ``unused_import``, but for ``extern crate`` statements. It is related to feature request #10385.
I adapted the code tracking used imports so that it tracks extern crates usage as well. This was mainly trial and error and while I believe all cases are covered, there might be some code I added that is useless (long compile times didn't give me the opportunity to check this in detail).
Also, I removed some unused ``extern crate`` statements from the libs, that where spotted by this new lint.
The spans inside of these types were always None and never used. Pass
the expander function directly instead of wrapping it in one of these
types.
[breaking-change]
This allows code to access the fields of tuples and tuple structs behind the feature gate `tuple_indexing`:
```rust
#![feature(tuple_indexing)]
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);
```
Implements [RFC 53](https://github.com/rust-lang/rfcs/blob/master/active/0053-tuple-accessors.md). Closes#16950.
For convenience, the traits are implemented for the respective bare
functions. Change code from this:
```rust
ItemDecorator(some_function)
// or
ItemModifier(some_other_function)
```
to
```rust
ItemDecorator(box some_function)
// or
ItemModifier(box some_other_function)
```
[breaking-change]
Based on an observation that strings and arguments are always interleaved, thanks to #15832. Additionally optimize invocations where formatting parameters are unspecified for all arguments, e.g. `"{} {:?} {:x}"`, by emptying the `__STATIC_FMTARGS` array. Next, `Arguments::new` replaces an empty slice with `None` so that passing empty `__STATIC_FMTARGS` generates slightly less machine code when `Arguments::new` is inlined. Furthermore, formatting itself treats these cases separately without making redundant copies of formatting parameters.
All in all, this adds a single mov instruction per `write!` in most cases. That's why code size has increased.
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);
Format specs are ignored and not stored in case they're all default.
Restore default formatting parameters during iteration.
Pass `None` instead of empty slices of format specs to take advantage
of non-nullable pointer optimization.
Generate a call to one of two functions of `fmt::Argument`.
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]
Adjust the handling of `#[inline]` items so that they get translated into every
compilation unit that uses them. This is necessary to preserve the semantics
of `#[inline(always)]`.
Crate-local `#[inline]` functions and statics are blindly translated into every
compilation unit. Cross-crate inlined items and monomorphizations of
`#[inline]` functions are translated the first time a reference is seen in each
compilation unit. When using multiple compilation units, inlined items are
given `available_externally` linkage whenever possible to avoid duplicating
object code.
Use '^' to specify center alignment in format strings.
fmt!( "[{:^5s}]", "Hi" ) -> "[ Hi ]"
fmt!( "[{:^5s}]", "H" ) -> "[ H ]"
fmt!( "[{:^5d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^5d}]", -1i ) -> "[ -1 ]"
fmt!( "[{:^6d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^6d}]", -1i ) -> "[ -1 ]"
If the padding is odd then the padding on the right will be one
character longer than the padding on the left.
Tuples squashed
They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
Fixes#16648.
Enables any macros using `MacExpr` to be treated as patterns when
they produce a literal in the form `ExprLit` (e.g. `stringify!` or `line!`).
Fixes#16876.
They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
Fixes#16648.
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).
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
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
As of RFC 18, struct layout is undefined. Opting into a C-compatible struct
layout is now down with #[repr(C)]. For consistency, specifying a packed
layout is now also down with #[repr(packed)]. Both can be specified.
To fix errors caused by this, just add #[repr(C)] to the structs, and change
#[packed] to #[repr(packed)]
Closes#14309
[breaking-change]
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
declared with the same name in the same scope.
This breaks several common patterns. First are unused imports:
use foo::bar;
use baz::bar;
Change this code to the following:
use baz::bar;
Second, this patch breaks globs that import names that are shadowed by
subsequent imports. For example:
use foo::*; // including `bar`
use baz::bar;
Change this code to remove the glob:
use foo::{boo, quux};
use baz::bar;
Or qualify all uses of `bar`:
use foo::{boo, quux};
use baz;
... baz::bar ...
Finally, this patch breaks code that, at top level, explicitly imports
`std` and doesn't disable the prelude.
extern crate std;
Because the prelude imports `std` implicitly, there is no need to
explicitly import it; just remove such directives.
The old behavior can be opted into via the `import_shadowing` feature
gate. Use of this feature gate is discouraged.
This implements RFC #116.
Closes#16464.
[breaking-change]
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]
