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.
Add `#[rustc_error]` annotation, which causes trans to signal an error
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
r? @pnkfelix
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.
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
Names of structs, enums, traits, type aliases and type parameters (i.e. all identifiers that can be used as full paths in type position) are not allowed to match the names of primitive types.
See #20427 for more information.
This is a minor [breaking-change]
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
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Closes#8962Closes#16360Closes#20327
This renames the PrivateNoMangleFns lint to allow both to happen in a
single pass, since they do roughly the same work.
Closes#21856
Open questions:
[ ]: Do the tests actually pass (I'm running make check and running out the door now)
[ ]: Is the name of this lint ok. it seems to mostly be fine with [convention](cc53afbe5d/text/0344-conventions-galore.md (lints))
[ ]: I'm not super thrilled about the warning text
r? @kmcallister (Shamelessly nominating because you were looking at my other ticket)
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.
Closes#8962Closes#16360Closes#20327
[breaking-change]
This is a resurrection and heavy revision/expansion of a PR that pcwalton did to resolve#8861.
The most relevant, user-visible semantic change is this: #[unsafe_destructor] is gone. Instead, if a type expression for some value has a destructor, then any lifetimes referenced within that type expression must strictly outlive the scope of the value.
See discussion on https://github.com/rust-lang/rfcs/pull/769
Some compile-fail tests illustrated cases to be rejected by dropck,
including ones that check cyclic data cases designed to exposed bugs
if they are actually tricked into running by an unsound analysis.
E.g. these exposed bugs in earlier broken ways of handling `Vec<T>`.
(Note that all the uses of `unsafe_destructor` are just placating the
simple analysis used for that feature, which will eventually go away
once we have put the dropck through its paces.)
```rust
#[plugin] #[no_link] extern crate bleh;
```
becomes a crate attribute
```rust
#![plugin(bleh)]
```
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
#[plugin] #[no_link] extern crate bleh;
becomes a crate attribute
#![plugin(bleh)]
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library /
executable, because it will bring all of libsyntax and librustc with it.
However if you really want this behavior, you can get it with a separate
`extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
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 PR moves all `compile-fail` tests that fail at the parsing stage to a `parse-fail` directory, in order to use the tests in the `parse-fail` directory to test if the new LALR parser rejects the same files as the Rust parser. I also adjusted the `testparser.py` script to handle the tests in `parse-fail` differently.
However during working on this, I discovered, that Rust's parser sometimes fails during parsing, but does not return a nonzero return code, e.g. compiling `/test/compile-fail/doc-before-semi.rs` with `-Z parse-only` prints an error message, but returns status code 0. Compiling the same file without `-Z parse-only`, the same error message is displayed, but error code 101 returned. I'll look into that over the next week.
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.
Note that the change to the error message in
borrowck-use-in-index-lvalue.rs, where we report that `*w` is
uninitialized rather than `w`, was unintended fallout from the
implementation strategy used here.
The change appears harmless to me, but I welcome advice on how to
bring back the old message, which was slightly cleaner (i.e. less
unintelligible).
----
drive-by: revise compile-fail/borrowck-vec-pattern-move-tail to make
it really clear that there is a conflict that must be signaled.
(A hypothetical future version of Rust might be able to accept the
prior version of the code, since the previously updated index was not
actually aliased.)
