*Syntactically* permit visibilities on trait items & enum variants #66183
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
Centril
added
T-lang
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
Centril
force-pushed
the
empty-vis-trait-decl
branch
from
eff6bbe to
24ccd5b
Compare
Centril
commented
Nov 7, 2019
estebank
reviewed
Nov 7, 2019
| | ^^^ unexpected token | ||
| | -^^^^^^ expected one of 7 possible tokens here | ||
| | | | ||
| | help: `}` may belong here |
|
LGTM, but saw that @petrochenkov self-assigned, letting him sign off on it. |
|
So, I agree with the (direction of) the change for trait items, because that's a part of the syntactic unification of free/trait/impl/foreign items. I don't agree with accepting empty |
petrochenkov
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
Centril
force-pushed
the
empty-vis-trait-decl
branch
from
21e6c21 to
a428ba2
Compare
Centril
added
S-waiting-on-review
Centril
changed the title
:vis before trait item & enum variant
|
@petrochenkov Adjusted the PR to syntactically accept any visibility on enum variants & trait items now (discussion in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.2366183 -- cc @rust-lang/lang again in case anyone missed it) |
This comment has been minimized.
This comment has been minimized.
|
LGTM, but needs commit squashing and a pprust test update. |
|
Let's pass this through an FCP, I'm not sure the enum variant change has enough motivation and thus don't want to take responsibility for it. |
petrochenkov
added
needs-fcp
|
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
💔 Test failed - checks-azure |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Nov 22, 2019
…rochenkov *Syntactically* permit visibilities on trait items & enum variants Fixes rust-lang#65041 Suppose we have `$vis trait_item` or `$vis enum_variant` and `$vis` is a `:vis` macro fragment. Before this PR, this would fail to parse. This is now instead allowed as per language team consensus in rust-lang#65041 (comment). (See added tests for elaboration.) Moreover, we now also permit visibility modifiers on trait items & enum variants *syntactically* but reject them with semantic checks (in `ast_validation`): ```rust #[cfg(FALSE)] trait Foo { pub fn bar(); } // OK #[cfg(FALSE)] enum E { pub U } // OK ```
|
⌛ Testing commit 9a88364 with merge 6e59650f84e783a1753508623e68e81f58175a85... |
|
@bors retry in r0llup |
bors
added a commit
that referenced
this pull request
Nov 22, 2019
Rollup of 8 pull requests Successful merges: - #66183 (*Syntactically* permit visibilities on trait items & enum variants) - #66566 (Document pitfall with `impl PartialEq<B> for A`) - #66575 (Remove pretty printing of specific nodes in AST) - #66587 (Handle statics in MIR as const pointers) - #66619 (follow the convention in this file to use third-person singular verbs) - #66633 (Error code's long explanation cleanup) - #66637 (fix reoccuring typo: dereferencable -> dereferenceable) - #66639 (resolve: more declarative `fresh_binding`) Failed merges: r? @ghost
rfcbot
added
finished-final-comment-period
|
@Centril What specifically about this should be mentioned in the release notes? For practical purposes nothing has really changed on the user facing side as far as I can tell, since they will get an error no matter what. |
|
@XAMPPRocky Most of the time nothing has changed for users. However, in niche circumstances, e.g. with a procedural macro, you can do e.g.: #[my_funky_attr]
enum Foo { pub Bar }
// ...expands to the following because `my_funky_attr` is funky:
struct Bar;
enum Foo { Bar(Bar) }The same logic applies to trait items. |
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this pull request
Feb 17, 2020
Version 1.41.0 (2020-01-30)
===========================
Language
--------
- [You can now pass type parameters to foreign items when implementing
traits.][65879] E.g. You can now write `impl<T> From<Foo> for Vec<T> {}`.
- [You can now arbitrarily nest receiver types in the `self` position.][64325] E.g. you can
now write `fn foo(self: Box<Box<Self>>) {}`. Previously only `Self`, `&Self`,
`&mut Self`, `Arc<Self>`, `Rc<Self>`, and `Box<Self>` were allowed.
- [You can now use any valid identifier in a `format_args` macro.][66847]
Previously identifiers starting with an underscore were not allowed.
- [Visibility modifiers (e.g. `pub`) are now syntactically allowed on trait items and
enum variants.][66183] These are still rejected semantically, but
can be seen and parsed by procedural macros and conditional compilation.
Compiler
--------
- [Rustc will now warn if you have unused loop `'label`s.][66325]
- [Removed support for the `i686-unknown-dragonfly` target.][67255]
- [Added tier 3 support\* for the `riscv64gc-unknown-linux-gnu` target.][66661]
- [You can now pass an arguments file passing the `@path` syntax
to rustc.][66172] Note that the format differs somewhat from what is
found in other tooling; please see [the documentation][argfile-docs] for
more information.
- [You can now provide `--extern` flag without a path, indicating that it is
available from the search path or specified with an `-L` flag.][64882]
\* Refer to Rust's [platform support page][forge-platform-support] for more
information on Rust's tiered platform support.
[argfile-docs]: https://doc.rust-lang.org/nightly/rustc/command-line-arguments.html#path-load-command-line-flags-from-a-path
Libraries
---------
- [The `core::panic` module is now stable.][66771] It was already stable
through `std`.
- [`NonZero*` numerics now implement `From<NonZero*>` if it's a smaller integer
width.][66277] E.g. `NonZeroU16` now implements `From<NonZeroU8>`.
- [`MaybeUninit<T>` now implements `fmt::Debug`.][65013]
Stabilized APIs
---------------
- [`Result::map_or`]
- [`Result::map_or_else`]
- [`std::rc::Weak::weak_count`]
- [`std::rc::Weak::strong_count`]
- [`std::sync::Weak::weak_count`]
- [`std::sync::Weak::strong_count`]
Cargo
-----
- [Cargo will now document all the private items for binary crates
by default.][cargo/7593]
- [`cargo-install` will now reinstall the package if it detects that it is out
of date.][cargo/7560]
- [Cargo.lock now uses a more git friendly format that should help to reduce
merge conflicts.][cargo/7579]
- [You can now override specific dependencies's build settings][cargo/7591] E.g.
`[profile.dev.overrides.image] opt-level = 2` sets the `image` crate's
optimisation level to `2` for debug builds. You can also use
`[profile.<profile>.build_overrides]` to override build scripts and
their dependencies.
Misc
----
- [You can now specify `edition` in documentation code blocks to compile the block
for that edition.][66238] E.g. `edition2018` tells rustdoc that the code sample
should be compiled the 2018 edition of Rust.
- [You can now provide custom themes to rustdoc with `--theme`, and check the
current theme with `--check-theme`.][54733]
- [You can use `#[cfg(doc)]` to compile an item when building documentation.][61351]
Compatibility Notes
-------------------
- [As previously announced 1.41.0 will be the last tier 1 release for 32-bit
Apple targets.][apple-32bit-drop] This means that the source code is still
available to build, but the targets are no longer being tested and release
binaries for those platforms will no longer be distributed by the Rust project.
Please refer to the linked blog post for more information.
[54733]: rust-lang/rust#54733
[61351]: rust-lang/rust#61351
[67255]: rust-lang/rust#67255
[66661]: rust-lang/rust#66661
[66771]: rust-lang/rust#66771
[66847]: rust-lang/rust#66847
[66238]: rust-lang/rust#66238
[66277]: rust-lang/rust#66277
[66325]: rust-lang/rust#66325
[66172]: rust-lang/rust#66172
[66183]: rust-lang/rust#66183
[65879]: rust-lang/rust#65879
[65013]: rust-lang/rust#65013
[64882]: rust-lang/rust#64882
[64325]: rust-lang/rust#64325
[cargo/7560]: rust-lang/cargo#7560
[cargo/7579]: rust-lang/cargo#7579
[cargo/7591]: rust-lang/cargo#7591
[cargo/7593]: rust-lang/cargo#7593
[`Result::map_or_else`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or_else
[`Result::map_or`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or
[`std::rc::Weak::weak_count`]: https://doc.rust-lang.org/std/rc/struct.Weak.html#method.weak_count
[`std::rc::Weak::strong_count`]: https://doc.rust-lang.org/std/rc/struct.Weak.html#method.strong_count
[`std::sync::Weak::weak_count`]: https://doc.rust-lang.org/std/sync/struct.Weak.html#method.weak_count
[`std::sync::Weak::strong_count`]: https://doc.rust-lang.org/std/sync/struct.Weak.html#method.strong_count
[apple-32bit-drop]: https://blog.rust-lang.org/2020/01/03/reducing-support-for-32-bit-apple-targets.html
|
Concrete use case: DSL for a Java-style enum (https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html). Java: public enum Planet {
MERCURY (3.301e+23, 2.440e+6),
VENUS (4.868e+24, 6.052e+6),
EARTH (5.972e+24, 6.371e+6),
MARS (6.417e+23, 3.390e+6),
JUPITER (1.898e+27, 6.991e+7),
SATURN (5.683e+26, 5.823e+7),
URANUS (8.681e+25, 2.536e+7),
NEPTUNE (1.024e+26, 2.462e+7);
private final double mass;
private final double radius;
Planet(double mass, double radius) {
this.mass = mass;
this.radius = radius;
}
// additional methods
}Rust: #[aux_enum_data]
pub enum Planet {
Mercury = (3.301e+23, 2.440e+6),
Venus = (4.868e+24, 6.052e+6),
Earth = (5.972e+24, 6.371e+6),
Mars = (6.417e+23, 3.390e+6),
Jupiter = (1.898e+27, 6.991e+7),
Saturn = (5.683e+26, 5.823e+7),
Uranus = (8.681e+25, 2.536e+7),
Neptune = (1.024e+26, 2.462e+7),
pub PlanetFacts {
pub mass: f64,
pub radius: f64,
}
}Expands to: #[derive(Copy, Clone, PartialEq, Eq, Hash)]
pub enum Planet {
Mercury,
Venus,
Earth,
Mars,
Jupiter,
Saturn,
Uranus,
Neptune,
}
pub struct PlanetFacts {
pub mass: f64,
pub radius: f64,
}
impl std::ops::Deref for Planet {
type Target = PlanetFacts;
fn deref(&self) -> &Self::Target {
match self {
Planet::Mercury => &PlanetFacts { mass: 3.301e+23, radius: 2.440e+6 },
Planet::Venus => &PlanetFacts { mass: 4.868e+24, radius: 6.052e+6 },
Planet::Earth => &PlanetFacts { mass: 5.972e+24, radius: 6.371e+6 },
Planet::Mars => &PlanetFacts { mass: 6.417e+23, radius: 3.390e+6 },
Planet::Jupiter => &PlanetFacts { mass: 1.898e+27, radius: 6.991e+7 },
Planet::Saturn => &PlanetFacts { mass: 5.683e+26, radius: 5.823e+7 },
Planet::Uranus => &PlanetFacts { mass: 8.681e+25, radius: 2.536e+7 },
Planet::Neptune => &PlanetFacts { mass: 1.024e+26, radius: 2.462e+7 },
}
}
}println!("1 earth mass = {} kg", Earth.mass); |
tmandry
added a commit
to tmandry/rust
that referenced
this pull request
Sep 10, 2020
Syntactically permit unsafety on mods Similar to rust-lang#66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust. ```rust #[mymacro] unsafe mod m { ... } #[mymacro] unsafe extern "C++" { ... } ``` The intention is that this might be used as a kind of "item-level unsafe" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx. In the absence of a procedural macro rewriting them to something else, they'll continue to be rejected at compile time though with a better error message than before. ### Before: ```console error: expected item, found keyword `unsafe` --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ expected item ``` ### After: ```console error: module cannot be declared unsafe --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ error: extern block cannot be declared unsafe --> src/main.rs:4:1 | 4 | unsafe extern "C++" { | ^^^^^^ ``` Closes rust-lang#68048.
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.
Fixes #65041
Suppose we have
$vis trait_itemor$vis enum_variantand$visis a:vismacro fragment. Before this PR, this would fail to parse. This is now instead allowed as per language team consensus in #65041 (comment). (See added tests for elaboration.)Moreover, we now also permit visibility modifiers on trait items & enum variants syntactically but reject them with semantic checks (in
ast_validation):