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
Fixes#18567. `Struct{x:foo, .. with_expr}` did not walk `with_expr`, which allowed
using moved variables in some cases. The CFG for structs also built up with
`with_expr` happening before the fields, which is now reversed. (Fields are now
before the `with_expr` in the CFG)
Fixes#18567. Struct{x:foo, .. with_expr} did not walk with_expr, which allowed
using moved variables in some cases. The CFG for structs also built up with
with_expr happening before the fields, which is now reversed. (Fields are now
before the with_expr in the CFG)
This commit adds support for linting `extern crate` statements for stability
attributes attached to the crate itself. This is likely to be the mechanism used
to deny access to experimental crates that are part of the standard
distribution.
cc #18585
r? @aturon
`eq`, `ne`, `cmp`, etc methods now require one less level of indirection when dealing with `&str`/`&[T]`
``` rust
"foo".ne(&"bar") -> "foo".ne("bar")
slice.cmp(&another_slice) -> slice.cmp(another_slice)
// slice and another_slice have type `&[T]`
```
[breaking-change]
Key points are:
1. `a + b` maps directly to `Add<A,B>`, where `A` and `B` are the types of `a` and `b`.
2. Indexing and slicing autoderefs consistently.
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 adds support for linting `extern crate` statements for stability
attributes attached to the crate itself. This is likely to be the mechanism used
to deny access to experimental crates that are part of the standard
distribution.
cc #18585
Closes#18126.
At the moment this mostly only changes notes that are particularly help-oriented or directly suggest the user to do something to help messages, and does not change messages that simply explain an error message further. If it is decided that those messages should also be help messages, I can add them to this PR, but for now I’m excluding them as I believe that changing those messages might leave very few places where notes would be appropriate.
Add lint for checking exceeding bitshifts #17713
It also const-evaluates the shift width (RHS) to check more complex shifts like `1u8 << (4+5)`.
The lint-level is set to `Warn` but perhaps it must be `Deny` as in llvm exceeding bitshifts are undefined as @ben0x539 stated in #17713
As part of the collections reform RFC, this commit removes all collections
traits in favor of inherent methods on collections themselves. All methods
should continue to be available on all collections.
This is a breaking change with all of the collections traits being removed and
no longer being in the prelude. In order to update old code you should move the
trait implementations to inherent implementations directly on the type itself.
Note that some traits had default methods which will also need to be implemented
to maintain backwards compatibility.
[breaking-change]
cc #18424
This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following:
```rust
mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6 let a: Result<uint, ()> = None;
^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7 f(42u);
^~~
```
tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.
```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>`
<anon>:6 let a: Result<uint, ()> = None;
^~~~
mismatched types: expected `&mut _`, found `uint`
<anon>:7 f(42u);
^~~
```
As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is:
```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>`
<anon>:6 let a: Result<uint, ()> = Some(1);
```
and float variables:
```rust
mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>`
<anon>:6 let a: Result<uint, ()> = Some(0.5);
```
[0] https://twitter.com/coda/status/517713085465772032
Closes https://github.com/rust-lang/rust/issues/2632.
Closes https://github.com/rust-lang/rust/issues/3404.
Closes https://github.com/rust-lang/rust/issues/18426.
This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new
flag to the compiler, `-l`, as well as tweaking the `include!` macro (and
related source-centric macros).
The compiler's new `-l` flag is used to link libraries in from the command line.
This flag stacks with `#[link]` directives already found in the program. The
purpose of this flag, also stated in the RFC, is to ease linking against native
libraries which have wildly different requirements across platforms and even
within distributions of one platform. This flag accepts a string of the form
`NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework.
This is roughly equivalent to if the equivalent `#[link]` directive were just
written in the program.
The `include!` macro has been modified to recursively expand macros to allow
usage of `concat!` as an argument, for example. The use case spelled out in RFC
403 was for `env!` to be used as well to include compile-time generated files.
The macro also received a bit of tweaking to allow it to expand to either an
expression or a series of items, depending on what context it's used in.
[rfc]: https://github.com/rust-lang/rfcs/pull/403
