about summary refs log tree commit diff
path: root/src/libsyntax/parse/parser.rs
AgeCommit message (Collapse)AuthorLines
2019-10-14Rollup merge of #65363 - Centril:less-pprust, r=Mark-SimulacrumMazdak Farrokhzad-2/+4
Remove implicit dependencies on syntax::pprust Part of https://github.com/rust-lang/rust/pull/65324. The main goal here is to facilitate the eventual move of pprust out from libsyntax and because an AST definition typically should not depend on its pretty printer. r? @estebank
2019-10-13syntax: consolidate function parsing in `item.rs`Mazdak Farrokhzad-281/+4
2019-10-13ast: remove implicit pprust dependency via Display.Mazdak Farrokhzad-2/+4
Instead just use `pprust::path_to_string(..)` where needed. This has two benefits: a) The AST definition is now independent of printing it. (Therefore we get closer to extracting a data-crate.) b) Debugging should be easier as program flow is clearer.
2019-10-07syntax: unify and simplify fn signature parsing.Mazdak Farrokhzad-58/+38
2019-10-07Auto merge of #64906 - Aaron1011:feature/extern-const-fn, r=Centrilbors-0/+9
Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: https://github.com/rust-lang/rust/issues/64926.
2019-10-02syntax: improve parameter without type suggestionsDavid Wood-0/+1
This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types, which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only `,` and `)` or trait items), this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap<u32>)` -> `fn foo(HashMap: TypeName<u32>)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood <david@davidtw.co>
2019-10-02Add support for 'extern const fn'Aaron Hill-0/+9
This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.
2019-10-01syntax: de-closure-ify `check_or_expected`.Mazdak Farrokhzad-7/+7
2019-10-01syntax: merge things back into `parse_visibility`.Mazdak Farrokhzad-37/+25
2019-10-01syntax: put helpers of `parse_self_param` in the method.Mazdak Farrokhzad-58/+57
2019-10-01syntax: document some methods.Mazdak Farrokhzad-2/+6
2019-09-30syntax: extract `error_on_invalid_abi`.Mazdak Farrokhzad-14/+17
2019-09-30syntax: cleanup `parse_visibility`.Mazdak Farrokhzad-53/+69
2019-09-30syntax: misc cleanupMazdak Farrokhzad-44/+30
2019-09-30syntax: reorder param parsing to make more sense.Mazdak Farrokhzad-153/+153
2019-09-30syntax refactor `parse_self_param` (5)Mazdak Farrokhzad-22/+21
2019-09-30syntax refactor `parse_self_param` (4)Mazdak Farrokhzad-24/+35
2019-09-30syntax refactor `parse_self_param` (3)Mazdak Farrokhzad-28/+20
2019-09-30syntax refactor `parse_self_param` (2)Mazdak Farrokhzad-11/+16
2019-09-30syntax refactor `parse_self_param` (1)Mazdak Farrokhzad-12/+13
2019-09-30syntax refactor `parse_fn_params`Mazdak Farrokhzad-28/+29
2019-09-30syntax: `is_named_argument` -> `is_named_param`.Mazdak Farrokhzad-2/+2
2019-09-29Rollup merge of #64894 - Centril:fix-64682, r=petrochenkovMazdak Farrokhzad-50/+23
syntax: fix dropping of attribute on first param of non-method assocated fn Fixes #64682. The general idea is that we bake parsing of `self` into `parse_param_general` and then we just use standard list parsing. Overall, this simplifies the parsing and makes it more consistent. r? @petrochenkov cc @c410-f3r
2019-09-29syntax: fix #64682.Mazdak Farrokhzad-50/+23
Fuse parsing of `self` into `parse_param_general`.
2019-09-28syntax: don't keep a redundant c_variadic flag in the AST.Eduard-Mihai Burtescu-3/+4
2019-09-26Rename `Ty.node` to `Ty.kind`varkor-1/+1
2019-09-11Stabilize `param_attrs` in Rust 1.39.0Caio-2/+2
2019-09-09Resolve attributes in several placesCaio-1/+8
Arm, Field, FieldPat, GenericParam, Param, StructField and Variant
2019-09-07Aggregation of cosmetic changes made during work on REPL PRs: libsyntaxAlexander Regueiro-25/+25
2019-09-06reduce visibilityAleksey Kladov-11/+11
2019-08-28Auto merge of #63127 - kper:pr, r=nikomatsakisbors-48/+50
Cleanup: Consistently use `Param` instead of `Arg` #62426 Fixes #62426
2019-08-27Cleanup: Consistently use `Param` instead of `Arg` #62426Kevin Per-48/+50
2019-08-27Rollup merge of #63761 - petrochenkov:procattrs, r=eddybMazdak Farrokhzad-4/+5
Propagate spans and attributes from proc macro definitions Thanks to https://github.com/rust-lang/rust/pull/63269 we now have spans and attributes from proc macro definitions available in metadata. However, that PR didn't actually put them into use! This PR finishes that work. Attributes `rustc_macro_transparency`, `allow_internal_unstable`, `allow_internal_unsafe`, `local_inner_macros`, `rustc_builtin_macro`, `stable`, `unstable`, `rustc_deprecated`, `deprecated` now have effect when applied to proc macro definition functions. From those attributes only `deprecated` is both stable and supposed to be used in new code. (`#![staged_api]` still cannot be used in proc macro crates for unrelated reasons though.) `Span::def_site` from the proc macro API now returns the correct location of the proc macro definition. Also, I made a mistake in https://github.com/rust-lang/rust/pull/63269#discussion_r312702919, loaded proc macros didn't actually use the resolver cache. This PR fixes the caching issue, now proc macros go through the `Resolver::macro_map` cache as well. (Also, the first commit turns `proc_macro::quote` into a regular built-in macro to reduce the number of places where `SyntaxExtension`s need to be manually created.)
2019-08-27proc_macro: Update `Span::def_site` to use the proc macro definition locationVadim Petrochenkov-4/+5
Which is no longer dummy and is available from metadata now.
2019-08-25parser: gracefully handle `fn foo(A | B: type)`.Mazdak Farrokhzad-1/+1
2019-08-24parser: drive-by: simplify `parse_arg_general`.Mazdak Farrokhzad-6/+3
2019-08-15hygiene: Remove `Option`s from functions returning `ExpnInfo`Vadim Petrochenkov-1/+0
The expansion info is not optional and should always exist
2019-08-15syntax_pos: Introduce a helper for checking whether a span comes from expansionVadim Petrochenkov-1/+1
2019-08-12syntax: account for CVarArgs being in the argument list.Eduard-Mihai Burtescu-1/+1
2019-08-11parser: {check,expect}_lifetime into ty.rsMazdak Farrokhzad-17/+1
2019-08-11parser: move into generics.rsMazdak Farrokhzad-270/+2
2019-08-11parser: move into stmt.rsMazdak Farrokhzad-458/+9
2019-08-11parser: move parse_fn_block_decl into expr.rsMazdak Farrokhzad-51/+1
2019-08-11parser: move parse_ident_or_underscore into item.rsMazdak Farrokhzad-11/+0
2019-08-11parser: split into {ty, path}.rsMazdak Farrokhzad-899/+9
2019-08-11parser: split into {item,module}.rsMazdak Farrokhzad-2218/+20
2019-08-11parser: split into pat.rsMazdak Farrokhzad-633/+8
2019-08-11parser: split into expr.rsMazdak Farrokhzad-1667/+9
2019-08-09Recover parser from `foo(_, _)`Esteban Küber-20/+50
2019-08-04Auto merge of #63213 - varkor:itemkind-tyalias, r=Centrilbors-2/+2
Rename `ItemKind::Ty` to `ItemKind::TyAlias` The current name is not entirely clear without context and `TyAlias` is consistent with `ItemKind::TraitAlias`.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 06:12:22 +0000