-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Consider turning "visibility has no effect inside functions" into a lint #31776
Comments
Yeah, this restriction is pretty artificial, it isn't required for anything else. |
I'm not sure a RFC is needed a small that little. cc @pnkfelix |
Moreover, the "visibility has no effect inside functions or block expressions" statement is not correct, Example 1: Rustdoc. Rustdoc wraps code snippets in Example 2: Inherent methods.
Example 3: Pulling a function local type out of function through a public impl
Example 4: Field of a function local type
Example 5: Any other private-in-public scenario in function local modules
|
I agree, that the examples above are contrived, but they are still possible. |
triage: I-nominated (I suspect this is a P-medium issue.) I suspect we can do this without an RFC (though I could imagine some of the details about interaction with private-in-public checking may lead to unanticipated results that could justify one...) |
This example makes me think that a lint would be wrong: pub trait Tr {
type A;
}
pub struct S;
fn f() {
struct Z;
impl ::Tr for ::S {
type A = Z; // Private-in-public error unless `struct Z` is pub
}
}
fn main() {} After all, in this case you have to use |
Discussed in @rust-lang/lang meeting and conclusion was that we should just drop this restriction and not replace it with a lint, due to aforementioned examples. triage: P-medium |
Remove some FIXMEs now that rust-lang/rust#31776 has been fixed
The current code results in a hard error:
This can be painful when writing macros that generate structs or inherent methods, which would otherwise need to be public (particularly when writing tests for those macros). This doesn't seem like something which should need to be an error, and could instead be a lint (which is
deny
by default). I'm unsure if this would need a full RFC or not, and was told that it'd be best to open an issue to start.The text was updated successfully, but these errors were encountered: