This commit deals with the fallout of the previous change by making tuples
structs have public fields where necessary (now that the fields are private by
default).
This is a continuation of the work done in #13184 to make struct fields private
by default. This commit finishes RFC 4 by making all tuple structs have private
fields by default. Note that enum variants are not affected.
A tuple struct having a private field means that it cannot be matched on in a
pattern match (both refutable and irrefutable), and it also cannot have a value
specified to be constructed. Similarly to private fields, switching the type of
a private field in a tuple struct should be able to be done in a backwards
compatible way.
The one snag that I ran into which wasn't mentioned in the RFC is that this
commit also forbids taking the value of a tuple struct constructor. For example,
this code now fails to compile:
mod a {
pub struct A(int);
}
let a: fn(int) -> a::A = a::A; //~ ERROR: first field is private
Although no fields are bound in this example, it exposes implementation details
through the type itself. For this reason, taking the value of a struct
constructor with private fields is forbidden (outside the containing module).
RFC: 0004-private-fields
This is an implementation of a portion of [RFC #4](https://github.com/rust-lang/rfcs/blob/master/active/0004-private-fields.md). This PR makes named struct fields private by default (as opposed to inherited by default).
The only real meaty change is the first commit to `rustc`, all other commits are just fallout of that change.
Summary of changes made:
* Named fields are private by default *everywhere*
* The `priv` keyword is now default-deny on named fields (done in a "lint" pass in privacy)
Changes yet to be done (before the RFC is closed)
* Change tuple structs to have private fields by default
* Remove `priv` enum variants
* Make `priv` a reserved keyword
The `Float` trait methods will be usable as functions via UFCS, and
we came to a consensus to remove duplicate functions like this a long
time ago.
It does still make sense to keep the duplicate functions when the trait
methods are static, unless the decision to leave out the in-scope trait
name resolution for static methods changes.
This commit switches privacy's checking of fields to have *all* fields be
private by default. This does not yet change tuple structs, this only affects
structs with named fields. The fallout of this change will follow shortly.
RFC: 0004-private-fields
cc #8122Closes#11809
The implementation of `Encodable<E, S>` for `Json` doesn't need to assume `S` to be `IoError`, only the default encoders for `Json` are depend on it. So this can be parametrize to increase flexiblity. If not, types that implement `Encoder<E>` where `E` is not `IoError` can't be worked with `Json`.
Mac can't actually build our source tarballs because it's `tar`
command doesn't support the --exclude-vcs flag. This is just
a workaround to make our mac nightlies work (we get our source
tarballs from the linux bot).
