Integrate privacy into autoderef loop with overloaded deref #12808
Comments
|
cc @eddyb |
|
Nominating for 1.0 P-Backcompat-lang. |
|
Assigning 1.0, P-backcompat-lang. |
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
cc rust-lang#12808
Paper over privacy issues with Deref by changing field names.
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
cc #12808
|
Thinking about this, I don't believe this is backwards incompatible per se. The worst thing that can happen is that, under today's rules, the method resolver will be led astray by a method that is private, and the program will fail to compile. To be sure, this will prevent us from adding new methods to smart pointers like Marking this as not-blocking-1.0 reduces schedule risk because this is a fairly involved change that carves up privacy and moves large swathes of it to pre-typechecking and typechecking phases. |
|
Downgradiing to P-high, leaving on the 1.0 milestone, following the reasoning outlined by @pcwalton in #12808 (comment) @nikomatsakis : you may want to weigh in here on this recategorization. |
|
Nominating; I'm unclear on the status of this, but we should decide whether it merits a -beta milestone. |
|
leaving on 1.0 milestone. @nikomatsakis you may want to double-check whether that is good (versus promoting to 1.0-beta milestone). |
|
@nikomatsakis would like to see this fixed by 1.1. So, assinging to @nikomatsakis and putting on 1.1 milestone. |
The fixed issue that allowed this was rust-lang#12808.
Remove strange names created by lack of privacy-conscious name lookup The fixed issue that allowed this was rust-lang#12808.
Remove strange names created by lack of privacy-conscious name lookup The fixed issue that allowed this was rust-lang#12808.
Remove strange names created by lack of privacy-conscious name lookup The fixed issue that allowed this was rust-lang#12808.
|
There is a FIXME related to this issue, |
rust-lang#12808 is closed remove the FIXME let's see if this can be cleaned up. rust-lang#12808 (comment)
rust-lang#12808 is closed remove the FIXME let's see if this can be cleaned up. rust-lang#12808 (comment)
The double underscores were used to work around issue rust-lang#12808, which was solved in 2016.
feat: Only flycheck workspace that belongs to saved file Supercedes rust-lang/rust-analyzer#11038 There is still the problem that all the diagnostics are cleared, only clearing diagnostics of the relevant workspace isn't easily doable though I think, will have to dig into that
Once PR #12610 lands, the autoderef loop will be generalized to permit dereferencing through user-defined structures that implement the
Dereftrait. As such, the termination condition becomes less clear around privacy. Currently, when searching for fields, we autoderef until finding a struct and then search for a field. In PR #12610, we will continue searching if no field with the desired name is found. Unfortunately, the PR does not consider privacy, and thus adding a field to a smart pointer can shadow fields in the referent. The same applies to methods. This is suboptimal.The desired behavior is that private fields and methods are ignored as part of the autoderef loop, so long as the expression being autoderef'd is not part of the module where the field/method was defined. This is a relatively simple check: if the field/method is declared private, you find the module M containing the declaration. You then check the whether current module N is a equal to M or a submodule of M. If not, you ignore the field/method.
For better error messages, it would be nice to at least track whether a private field/method with a suitable name was seen, so that we can report an error like "no accessible field
ffound (note that private fields were found)" or something like that.The text was updated successfully, but these errors were encountered: