Skip to content
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

Don't warn on use of a deprecated item in a deprecated item #9057

Closed
emberian opened this issue Sep 8, 2013 · 9 comments
Closed

Don't warn on use of a deprecated item in a deprecated item #9057

emberian opened this issue Sep 8, 2013 · 9 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@emberian
Copy link
Member

emberian commented Sep 8, 2013

For example:

#[deprecated]
fn foo() { }

#[deprecated]
fn bar() { foo() }

Should not be a warning.

@emberian
Copy link
Member Author

emberian commented Sep 8, 2013

#6875

@huonw
Copy link
Member

huonw commented Sep 8, 2013

(Similarly for experimental and unstable, etc.)

Should this also consider the case when bar is not marked deprecated but it is placed inside a module marked deprecated?

@emberian
Copy link
Member Author

emberian commented Sep 8, 2013

@huonw probably

@alexcrichton
Copy link
Member

I like the idea of: if any parent of yours is unstable, you're allowed to make unstable calls. Equivalently for other stability indices.

@huonw
Copy link
Member

huonw commented Sep 9, 2013

Presumably it's the first parent with a stability annotation that's the stability we should be caring about? So foo can make experimental calls, but not deprecated ones in the following:

#[deprecated]
mod x {
  #[experimental]
  mod y {
    fn foo() {
      experimental(); // ok
      deprecated(); // "warning: use of deprecated item"
    }
  }
}

(The stability attributes checking could easily get very slow since it will have to traverse the tree upward and parse the attributes on each parent item for every single function/method call and uses of structs/enums etc etc; it's probably worth using some caches for this information.)

@alexcrichton
Copy link
Member

OK, I'm ok with the closest-parent. I'd also be OK with not re-defining the stability index, or possibly not in some directions. deprecated => experimental doesn't really make sense to me...

In theory this can be done in two passes over the ast (with lots of space), one to collect the level of all items and one to process all of them, but that may be overkill.

@metajack
Copy link
Contributor

Bug triage. This is very similar to the dead_code lint change that we made that considers code marked with #[allow(dead_code)] to be live. See #11471

@steveklabnik
Copy link
Member

Triage: this system isn't really considered for external code anymore, so I wonder how important it is. Also, the original code sample does not warn for me today, which seems...odd.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 23, 2015
@steveklabnik
Copy link
Member

Updated code:

#![feature(staged_api)]
#![staged_api]

#[deprecated(since = "1.6.0", reason = "")]
#[stable(since = "1.6.0", feature="lol")]
fn foo() { }

#[deprecated(since = "1.6.0", reason = "")]
#[stable(since = "1.6.0", feature="lol")]
fn bar() { foo() }

fn main() {}

I agree with my own comment from ten months ago, and this hasn't had any non-triage activity for two years, so I'm just going to give a close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

No branches or pull requests

5 participants