Skip to content

mark private functions/globals not used in inline functions as internal #9495

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

Closed
thestinger opened this issue Sep 25, 2013 · 3 comments
Closed
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

We'll need to keep track of whether they're used in functions marked for cross-crate inlining, which may be tricky as this code isn't entirely centralized yet. I've been working towards getting it all passing through one place in base.rs so we're part of the way there...

@huonw
Copy link
Member

huonw commented Sep 25, 2013

I assume that rustc will have to handle something like

fn foo() {}
fn bar() {}
fn baz() {}

pub static FUNCS: &'static [extern "Rust" fn()] = &[foo, bar, baz];

too?

@alexcrichton
Copy link
Member

This I think needs some sort of dependency-graph-style abstraction for knowing when a function can never be called from an outside crate. Functions which can be called from outside crates are:

  • All functions located in exported_items
  • All non-generic functions called by some chain of generic functions rooted in an exported generic function.

Although that's probably not a complete list, I think to do this we need a hash of function id to a list of functions that could possibly be called, and then crawling can commence from there.

I'm also not sure if we're marking all instantiations of generic functions as internal, but we certainly can...

@huonw, that looks like an LLVM problem, and it still wouldn't matter too much because you can't cal foo by its name from an external crate, only by indexing into the FUNCS array which will just be pointers anyway.

@thestinger
Copy link
Contributor Author

This seems to be at least partly working as part of the reachable pass now. I'll open up more specific issues if I encounter them.

flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 6, 2022
Add `disallowed_macros` lint

Closes rust-lang#7790
Fixes rust-lang#9558

`clippy_utils::def_path_res` already resolved macro definitions which is nice, it just needed a tweak to be able to disambiguate e.g. `std::vec` the module & `std::vec` the macro, and `serde::Serialize` the trait & `serde::Serialize` the derive macro

changelog: new lint: [`disallowed_macros`]
changelog: [`disallowed_methods`], [`disallowed_types`]: Fix false negative when a type/fn/macro share the same path
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

3 participants