Skip to content

Prepare for private fields by default #13145

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 2 commits into from
Mar 27, 2014

Conversation

alexcrichton
Copy link
Member

This change prepares rustc to accept private fields by default. These changes will have to go through a snapshot before the rest of the changes can happen.

@alexcrichton
Copy link
Member Author

@flaper87
Copy link
Contributor

Looks good. Btw, if a change is meant for a specific RFC, I think the RFC should be mentioned in the commit message as well. For example, in OpenStack we use: implements-blueprint: the-name-of-the-blueprint, we could use something like: RFC: 0004-private-fields. Thoughts?

This is a necessary change in preparation for switching the defaults as part
of rust-lang#8122.

RFC: 0004-private-fields
This change is in preparation for rust-lang#8122. Nothing is currently done with these
visibility qualifiers, they are just parsed and accepted by the compiler.

RFC: 0004-private-fields
@alexcrichton
Copy link
Member Author

Sounds like a good idea to be! It certainly makes searching for commits related to an RFC easy to find.

bors added a commit that referenced this pull request Mar 26, 2014
This change prepares `rustc` to accept private fields by default. These changes will have to go through a snapshot before the rest of the changes can happen.
@bors bors closed this Mar 27, 2014
@bors bors merged commit 7de4841 into rust-lang:master Mar 27, 2014
@alexcrichton alexcrichton deleted the flip-some-defaults branch March 27, 2014 20:15
JohnTitor pushed a commit to JohnTitor/rust that referenced this pull request Sep 6, 2022
…jonas-schievink

feat: Add a "Unmerge match arm" assist to split or-patterns inside match expressions

Fixes rust-lang#13072.

The way I implemented it it leaves the `OrPat` in place even if there is only one pattern now but I don't think something will break because of that, and when more code will be typed we'll parse it again anyway. Removing it (but keeping the child pattern) is hard, I don't know how to do that.
flip1995 pushed a commit to flip1995/rust that referenced this pull request Aug 8, 2024
…hy, r=Jarcho

Make restriction lint's use `span_lint_and_then` (q -> w)

This migrates a few restriction lints to use `span_lint_and_then`. This change is motivated by rust-lang/rust-clippy#7797.

I've also cleaned up some lint message. Mostly minor stuff. For example: suggestions with a longer message than `"try"` now use `SuggestionStyle::ShowAlways`

---

cc: rust-lang/rust-clippy#7797

sister PR of: rust-lang/rust-clippy#13136

changelog: none
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants