Makes the compilation abort when a parse error is encountered while
trying to parse an item in an included file. The previous behaviour was
to stop processing the file when a token that can't start an item was
encountered, without producing any error. Fixes#21146.
This ends up propagating all the way out to the output of dep-info which then
makes Cargo think that files are not existent (it thinks the files have quotes
in their name) when they in fact do.
This commit performs a pass over the `std::macros` module, applying stability
attributes where necessary. In particular, this audits macros for patterns such
as:
* Standard use of forward-to-format-args via `$($arg:tt)*` (or `+`)
* Prevent macro-defined identifiers from leaking into expression arguments as
hygiene is not perfectly implemented.
* Wherever possible, `$crate` is used now.
Specifically, the following actions were taken:
* The `std::macros` module itself is no longer public.
* The `panic!` macro is stable
* The `assert!` macro is stable
* The `assert_eq!` macro is stable
* The `debug_assert!` macro is stable
* The `debug_assert_eq!` macro is stable
* The `unreachable!` macro is stable after removing the extra forms to bring the
definition in line with the `unimplemented!` macro.
* The `try!` macro is stable
* The `vec!` macro is stable
[breaking-change]
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning
when it is used.
[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md
[breaking-change]
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
This is an implementation of RFC 16. A module can now only be loaded if the
module declaring `mod name;` "owns" the current directory. A module is
considered as owning its directory if it meets one of the following criteria:
* It is the top-level crate file
* It is a `mod.rs` file
* It was loaded via `#[path]`
* It was loaded via `include!`
* The module was declared via an inline `mod foo { ... }` statement
For example, this directory structure is now invalid
// lib.rs
mod foo;
// foo.rs
mod bar;
// bar.rs;
fn bar() {}
With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be
renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`,
and can only be accessed through `foo`.
RFC: 0016-module-file-system-hierarchy
Closes#14180
[breaking-change]
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
How to update your code:
* Instead of `~EXPR`, you should write `box EXPR`.
* Instead of `~TYPE`, you should write `Box<Type>`.
* Instead of `~PATTERN`, you should write `box PATTERN`.
[breaking-change]
There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.
By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).
Closes#11692. Instead of returning the original expression, a dummy expression
(with identical span) is returned. This prevents infinite loops of failed
expansions as well as odd double error messages in certain situations.
