Add error message for private fn #79291
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
JulianKnodt
force-pushed
the
ce_priv
branch
7 times, most recently
from
912bf03
to
e12acb8
Compare
JulianKnodt
force-pushed
the
ce_priv
branch
2 times, most recently
from
3bb6317
to
387c1b9
Compare
lcnr
reviewed
Dec 3, 2020
JulianKnodt
commented
Dec 4, 2020
JohnCSimon
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
JulianKnodt
force-pushed
the
ce_priv
branch
3 times, most recently
from
09bb403
to
bf8224d
Compare
This comment has been minimized.
This comment has been minimized.
JulianKnodt
force-pushed
the
ce_priv
branch
2 times, most recently
from
f86c195
to
8a19f44
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Could someone explain me what's happening here from the language point of view? (Or even better send a patch to https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) (Also, I don't think the diagnostic change is an improvement, the message is talking about the function type specifically, the function itself may even be marked with |
petrochenkov
added
the
S-waiting-on-review
|
r=me with #79291 (comment) addressed and commits squashed, unless @lcnr has more comments. |
petrochenkov
added
S-waiting-on-author
Bless tests Update with changes from comments
|
@bors r+ |
|
📌 Commit 6a03f03 has been approved by |
bors
added
S-waiting-on-bors
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Feb 1, 2021
Add error message for private fn Attempts to add a more detailed error when a `const_evaluatable` fn from another scope is used inside of a scope which cannot access it. r? `@lcnr`
henryboisdequin
pushed a commit
to henryboisdequin/rust
that referenced
this pull request
Feb 1, 2021
Add error message for private fn Attempts to add a more detailed error when a `const_evaluatable` fn from another scope is used inside of a scope which cannot access it. r? ``@lcnr``
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 1, 2021
…as-schievink Rollup of 12 pull requests Successful merges: - rust-lang#78641 (Let io::copy reuse BufWriter buffers) - rust-lang#79291 (Add error message for private fn) - rust-lang#81364 (Improve `rustc_mir_build::matches` docs) - rust-lang#81387 (Move some tests to more reasonable directories - 3) - rust-lang#81463 (Rename NLL* to Nll* accordingly to C-CASE) - rust-lang#81504 (Suggest accessing field when appropriate) - rust-lang#81529 (Fix invalid camel case suggestion involving unicode idents) - rust-lang#81536 (Indicate both start and end of pass RSS in time-passes output) - rust-lang#81592 (Rustdoc UI fixes) - rust-lang#81594 (Avoid building LLVM just for llvm-dwp) - rust-lang#81598 (Fix calling convention for CRT startup) - rust-lang#81618 (Sync rustc_codegen_cranelift) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
lcnr
added
A-const-generics
16 tasks
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Dec 27, 2021
…ochenkov Relax priv-in-pub lint on generic bounds and where clauses of trait impls. The priv-in-pub lint is a legacy mechanism of the compiler, supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls. ## Current Behavior On public trait impls, it's currently an **error** to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // ERROR {} ``` ...and it's a **warning** to have have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} ``` This lint applies to `where` clauses in other contexts, too; e.g. on free functions: ```rust struct Priv<T>(T); pub trait Pub {} impl<T: Pub> Pub for Priv<T> {} pub fn function<T>() where Priv<T>: Pub // WARNING {} ``` **These constraints could be relaxed without issue.** ## New Behavior This lint is relaxed for `where` clauses on trait impls, such that it's okay to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // OK {} ``` ...and it's okay to have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // OK {} ``` ## Rationale While the priv-in-pub lint is not essential for soundness, it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance, such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context: ```rust fn callsite<T>() where Priv<T>: Pub // ERROR: omitting this bound is a compile error, but including it is too { function::<T>() } ``` ...it cannot do so without repeating `function`'s `where` bound, which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful. However, this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds, you don't need to forward those private bounds, you can forward the public trait: ```rust mod upstream { pub trait Trait { fn method(&self) {} } pub struct Type<T>(T); pub struct Pub<T>(T); trait Priv {} impl<T: Priv> Priv for Pub<T> {} impl<T> Trait for Type<T> where Pub<T>: Priv // WARNING {} } mod downstream { use super::upstream::*; fn function<T>(value: Type<T>) where Type<T>: Trait // <- no private deets! { value.method(); } } ``` **This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts, including trait definitions, inherent impls, and function definitions. It doesn't need to exist in those cases either, but I figured I'd first target a case where it's mostly pointless. ## Other Notes - See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397). - This PR effectively reverts rust-lang#79291.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Attempts to add a more detailed error when a
const_evaluatablefn from another scope is used inside of a scope which cannot access it.r? @lcnr