summary refs log tree commit diff
path: root/src/librustc_parse/parser
AgeCommit message (Collapse)AuthorLines
2020-01-21Rollup merge of #68140 - ecstatic-morse:const-trait-bound-opt-out, r=oli-obkMazdak Farrokhzad-20/+16
Implement `?const` opt-out for trait bounds For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment. Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR. After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering. cc #67794 r? @oli-obk
2020-01-20Parse `?const ?Trait`Dylan MacKenzie-18/+5
2020-01-20Add `MaybeConst` variant to `{ast,hir}::TraitBoundModifier`Dylan MacKenzie-9/+24
2020-01-19Store `impl const` in `ItemKind::Impl`Dylan MacKenzie-12/+4
2020-01-19Add `constness` field to `ast::ItemKind::Impl`Dylan MacKenzie-0/+2
2020-01-18remove rustc_error_codes deps except in rustc_driverMazdak Farrokhzad-6/+0
2020-01-17Use named fields for `ast::ItemKind::Impl`Dylan MacKenzie-10/+10
2020-01-16Rollup merge of #68096 - varkor:diagnostic-cleanup, r=CentrilDylan DPC-4/+4
Clean up some diagnostics by making them more consistent In general: - Diagnostic should start with a lowercase letter. - Diagnostics should not end with a full stop. - Ellipses contain three dots. - Backticks should encode Rust code. I also reworded a couple of messages to make them read more clearly. It might be sensible to create a style guide for diagnostics, so these informal conventions are written down somewhere, after which we could audit the existing diagnostics. r? @Centril
2020-01-15remove redundant clones, found by clippyMatthias Krüger-1/+1
2020-01-13Rollup merge of #68135 - calebcartwright:rustc-parse-visibilities, r=CentrilYuki Okushi-8/+17
restore some rustc_parse visibilities for rustfmt In https://github.com/rust-lang/rust/pull/65495/commits/c189565edc5c9fc516170885b3a3061b936205fb some visibilities were reduced on the parse mod (which now resides in the rustc_parse crate) as part of some refactoring and splitting up of libsyntax. However, rustfmt needs access to a few of those items that are no longer visible. This restores the visibility on those items rustfmt depends on. https://github.com/rust-lang/rustfmt/issues/3903#issuecomment-563596269 https://github.com/rust-lang/rustfmt/issues/4009 cc @topecongiro
2020-01-12Fix formatting ellipses at the end of some diagnosticsvarkor-2/+2
2020-01-12Add backticks in appropriate placesvarkor-2/+2
2020-01-12Rollup merge of #68108 - varkor:chained-comparison-suggestions, r=CentrilMazdak Farrokhzad-32/+93
Add suggestions when encountering chained comparisons Ideally, we'd also prevent the type error, which is just extra noise, but that will require moving the error from the parser, and I think the suggestion makes things clear enough for now. Fixes https://github.com/rust-lang/rust/issues/65659.
2020-01-11restore some rustc_parse visibilitiesCaleb Cartwright-8/+17
2020-01-11Rollup merge of #68120 - Centril:ban-range-to-dotdotdot, r=oli-obkMazdak Farrokhzad-4/+24
Ban `...X` pats, harden tests, and improve diagnostics Follow up to https://github.com/rust-lang/rust/pull/67258#issuecomment-565656155 and https://github.com/rust-lang/rust/pull/67258#discussion_r357879932. r? @cramertj @oli-obk
2020-01-11Ban `...X` pats, harden tests, and improve diagnostics.Mazdak Farrokhzad-4/+24
Also fix a bug with the span passed in `mk_range`.
2020-01-11Rollup merge of #68084 - estebank:ice-68000, r=varkorMazdak Farrokhzad-12/+9
Do not ICE on unicode next point Use `shrink_to_hi` instead of `next_point` and fix `next_point`. Fix #68000, fix #68091, fix #68092.
2020-01-11Add suggestions when encountering chained comparisonsvarkor-32/+93
2020-01-10Change `next_point` when `shrink_to_hi` is more appropriateEsteban Küber-11/+8
2020-01-10Introduce `#![feature(half_open_range_patterns)]`.Mazdak Farrokhzad-195/+134
This feature adds `X..`, `..X`, and `..=X` patterns.
2020-01-09Do not ICE on unicode next pointEsteban Küber-1/+1
Use `shrink_to_hi` instead of `next_point` Fix #68000.
2020-01-10Rollup merge of #68073 - Centril:fix-68062, r=estebankMazdak Farrokhzad-1/+1
expect `fn` after `const unsafe` / `const extern` Fixes #68062 r? @estebank @petrochenkov cc @Aaron1011
2020-01-10Rollup merge of #68071 - estebank:ice-67995, r=CentrilMazdak Farrokhzad-2/+6
Extend support of `_` in type parameters - Account for `impl Trait<_>`. - Provide a reasonable `Span` for empty `Generics` in `impl`s. - Account for `fn foo<_>(_: _) {}` to suggest `fn foo<T>(_: T) {}`. - Fix #67995. Follow up to #67597.
2020-01-09Reject `const` in inherent implsDylan MacKenzie-3/+12
2020-01-09Parse `?const Trait` bound syntaxDylan MacKenzie-14/+77
The grammar also handles `?const ?Trait` even though this is semantically redundant.
2020-01-09Parse `impl const Trait for Ty` syntaxDylan MacKenzie-3/+11
2020-01-09Extend support of `_` in type parametersEsteban Küber-2/+6
- Account for `impl Trait<_>`. - Provide a reasonable `Span` for empty `Generics` in `impl`s. - Account for `fn foo<_>(_: _) {}` to suggest `fn foo<T>(_: T) {}`. - Fix #67995.
2020-01-09expect `fn` after `const unsafe` / `const extern`Mazdak Farrokhzad-1/+1
2020-01-08- remove syntax::{span_warn!, span_err!, span_fatal!. struct_err!}Mazdak Farrokhzad-8/+5
- remove syntax::{help!, span_help!, span_note!} - remove unused syntax::{struct_span_fatal, struct_span_err_or_warn!, span_err_or_warn!} - lintify check_for_bindings_named_same_as_variants + conflicting_repr_hints - inline syntax::{struct_span_warn!, diagnostic_used!} - stringify_error_code! -> error_code! & use it more. - find_plugin_registrar: de-fatalize an error - de-fatalize metadata errors - move type_error_struct! to rustc_typeck - struct_span_err! -> rustc_errors
2020-01-04Rollup merge of #67835 - euclio:delimiter-wording, r=CentrilMazdak Farrokhzad-4/+4
tweak wording of mismatched delimiter errors This PR improves the wording of the "incorrect delimiter" error messages. Here's a quick rationale: - *"un-closed" -> "unclosed"*: "unclosed" is valid English, so there's no need to hyphenate the prefix. This should be pretty uncontroversial, I think. - *"close delimiter" -> "closing delimiter"*: In my anecdotal experience, I've always heard "closing delimiter" or "closing parenthesis". In addition, the codebase already uses this terminology in comments and function names more than "close delimiter", which could indicate that it's more intuitive. - "incorrect delimiter" -> "mismatched delimiter": "Incorrect delimiter" is vague; why is it incorrect? "mismatched" clearly indicates why the delimiter is causing the error. r? @estebank
2020-01-04Rollup merge of #67786 - Centril:canon-span, r=petrochenkovMazdak Farrokhzad-1/+1
Nix reexports from `rustc_span` in `syntax` Remove reexports `syntax::{source_map, symbol, edition}` and use `rustc_span` paths directly. r? @petrochenkov
2020-01-03tweak wording of mismatched delimiter errorsAndy Russell-4/+4
2020-01-03Rollup merge of #67807 - lzutao:toilet-closure, r=CentrilYuki Okushi-2/+2
Use drop instead of the toilet closure `|_| ()`
2020-01-02Normalize `syntax::source_map` imports.Mazdak Farrokhzad-1/+1
2020-01-02Use drop instead of the toilet closure `|_| ()`Lzu Tao-2/+2
2020-01-01Rename `syntax_pos` to `rustc_span` in source codeVadim Petrochenkov-22/+22
2019-12-31parser: bug -> span_bugMazdak Farrokhzad-7/+6
2019-12-31parser::diagnostics: remove fn fatalMazdak Farrokhzad-6/+3
2019-12-31parser::pat: remove .fatal callsMazdak Farrokhzad-11/+15
2019-12-31parser::path: remove .fatal callsMazdak Farrokhzad-10/+15
2019-12-31parser::module: remove .fatal callsMazdak Farrokhzad-1/+2
2019-12-31parser::item: remove .fatal callsMazdak Farrokhzad-8/+7
2019-12-31parser::attr: remove .fatal callsMazdak Farrokhzad-2/+4
2019-12-31process_potential_macro_variable: de-fatalize an errorMazdak Farrokhzad-2/+1
2019-12-31parser: span_fatal -> struct_span_errMazdak Farrokhzad-12/+8
2019-12-31de-fatalize some errorsMazdak Farrokhzad-8/+9
2019-12-31parser: call .struct_span_err directlyMazdak Farrokhzad-68/+56
2019-12-29Auto merge of #67112 - Centril:expr-polish, r=estebankbors-481/+497
Refactor expression parsing thoroughly Based on https://github.com/rust-lang/rust/pull/66994 together with which this has refactored basically the entirety of `expr.rs`. r? @estebank
2019-12-23Auto merge of #66296 - Centril:bindings_after_at-init, r=pnkfelixbors-0/+1
Initial implementation of `#![feature(bindings_after_at)]` Following up on #16053, under the gate `#![feature(bindings_after_at)]`, `x @ Some(y)` is allowed subject to restrictions necessary for soundness. The implementation and test suite should be fairly complete now. One aspect that is not covered is the interaction with nested `#![feature(or_patterns)]`. This is not possible to test at the moment in a good way because that feature has not progressed sufficiently and has fatal errors in MIR building. We should make sure to add such tests before we stabilize both features (but shipping one of them is fine). r? @pnkfelix cc @nikomatsakis @matthewjasper @pcwalton cc https://github.com/rust-lang/rust/issues/65490
2019-12-23Introduce `#![feature(bindings_after_at)]`.Mazdak Farrokhzad-0/+1
Under the gate, `x @ Some(y)` is allowed. This is subject to various restrictions for soundness.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 15:49:03 +0000