-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of deprecated item not propagated to macro expansion #20327
Comments
cc #12122 |
@alexcrichton That indeed appears to be the same issue - should this one be closed then? |
It's not quite the same because the feature gating code is separate from the stability level code, and #12122 is specifically about feature gates where this is specifically about stability levels. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 11, 2015
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::imp::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 rust-lang#8962 Closes rust-lang#16360 Closes rust-lang#20327 [breaking-change]
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 11, 2015
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::imp::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 rust-lang#8962 Closes rust-lang#16360 Closes rust-lang#20327
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the
spawn
function was deprecated in favour ofstd::thread::Thread::spawn
, the following program will produce a warningOutput:
But if the same call is wrapped in a macro the warning is not emitted, as follows:
Here it is on the playpen
Not sure if this is a bug or not, or if the warning should be emitted, but I would have expected the same warning when the macro is "unwrapped".
The text was updated successfully, but these errors were encountered: