-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
an empty :vis
doesn't work in trait declaration
#65041
Comments
@Centril |
This bit doesn't seem right; when I remove the Looking at
|
...actually it's not that odd. This code was likely written before we had the I think what we want to do is to use |
Sorry for the confusion caused by the comment. I edit the post, hope it is better now! |
:vis
doesn't work in trait declaration
We discussed this on the language team meeting today. The conclusion was that we regarded the issue here as a sort of bug that should be fixed (which I will do soon according to my notes above). We also took the opportunity to discuss the grand unification of the 3 item grammars that @petrochenkov raised in #64910 (comment). We found the idea of "grand unification" and moving to semantic errors to be generally appealing as well. |
Finally got around to this. I have a fix in #66183. |
Merge `TraitItem` & `ImplItem into `AssocItem` In this PR we: - Merge `{Trait,Impl}Item{Kind?}` into `AssocItem{Kind?}` as discussed in rust-lang#65041 (comment). - This is done by using the cover grammar of both forms. - In particular, it requires that we syntactically allow (under `#[cfg(FALSE)]`): - `default`ness on `trait` items, - `impl` items without a body / definition (`const`, `type`, and `fn`), - and associated `type`s in `impl`s with bounds, e.g., `type Foo: Ord;`. - The syntactic restrictions are replaced by semantic ones in `ast_validation`. - Move syntactic restrictions around C-variadic parameters from the parser into `ast_validation`: - `fn`s in all contexts now syntactically allow `...`, - `...` can occur anywhere in the list syntactically (`fn foo(..., x: usize) {}`), - and `...` can be the sole parameter (`fn foo(...) {}`. r? @petrochenkov
…enkov parse: merge `fn` syntax + cleanup item parsing Here we continue the work in rust-lang#67131 in particular to merge the grammars of `fn` items in various positions. A list of *language level* changes (as sanctioned by the language team in rust-lang#65041 (comment) and rust-lang#67131): - `self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used. - Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead. - Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns. - `const extern fn` feature gating is now done post-expansion such that we do not have conditional compatibilities of function qualifiers *in parsing*. - The `FnFrontMatter` grammar becomes: ```rust Extern = "extern" StringLit ; FnQual = "const"? "async"? "unsafe"? Extern? ; FnFrontMatter = FnQual "fn" ; ``` That is, all item contexts now *syntactically* allow `const async unsafe extern "C" fn` and use semantic restrictions to rule out combinations previously prevented syntactically. The semantic restrictions include in particular: - `fn`s in `extern { ... }` can have no qualifiers. - `const` and `async` cannot be combined. - To fuse the list-of-items parsing in the 4 contexts that items are allowed, we now must permit inner attributes (`#![attr]`) inside `trait Foo { ... }` definitions. That is, we now allow e.g. `trait Foo { #![attr] }`. This was probably an oversight due to not using a uniform parsing mechanism, which we now do have (`fn parse_item_list`). The semantic support (including e.g. for linting) falls out directly from the attributes infrastructure. To ensure this, we include a test for lints. Put together, these grammar changes allow us to substantially reduce the complexity of item parsing and its grammar. There are however some other non-language improvements that allow the compression to take place. A list of *compiler-internal* changes (in particular noting the parser-external data-structure changes): - We use `enum AllowPlus/RecoverQPath/AllowCVariadic { Yes, No }` in `parser/ty.rs` instead of passing around 3 different `bool`s. I felt this was necessary as it was becoming mentally taxing to track which-is-which. - `fn visit_trait_item` and `fn visit_impl_item` are merged into `fn visit_assoc_item` which now is passed an `AssocCtxt` to check which one it is. - We change `FnKind` to: ```rust pub enum FnKind<'a> { Fn(FnCtxt, Ident, &'a FnSig, &'a Visibility, Option<&'a Block>), Closure(&'a FnDecl, &'a Expr), } ``` with: ```rust pub enum FnCtxt { Free, Foreign, Assoc(AssocCtxt), } ``` This is then taken advantage of in tweaking the various semantic restrictions as well as in pretty printing. - In `ItemKind::Fn`, we change `P<Block>` to `Option<P<Block>>`. - In `ForeignItemKind::Fn`, we change `P<FnDecl>` to `FnSig` and `P<Block>` to `Option<P<Block>>`. - We change `ast::{Unsafety, Spanned<Constness>}>` into `enum ast::{Unsafe, Const} { Yes(Span), No }` respectively. This change in formulation allow us to exclude `Span` in the case of `No`, which facilitates parsing. Moreover, we also add a `Span` to `IsAsync` which is renamed to `Async`. The new `Span`s in `Unsafety` and `Async` are then taken advantage of for better diagnostics. A reason this change was made is to have a more uniform and clear naming scheme. The HIR keeps the structures in AST (with those definitions moved into HIR) for now to avoid regressing perf. - Various cleanups, bug fixes, and diagnostics improvements are made along the way. It is probably best to understand those via the diffs. I would recommend reviewing this commit-by-commit with whitespace changes hidden. r? @estebank @petrochenkov
I want to create a macro that generate
fn
s that use in bothimpl Item...
andtrait TraitName
. Intrait
,pub
must be omitted, but inimpl SomeStruct
I needpub
, so the macro need a$vis:vis
like this:Expected result:
create_method!(method_of_t1);
intrait T1
should works.(Edit: a better comment about the
:vis
inimpl Struct
)The text was updated successfully, but these errors were encountered: