about summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
2021-09-01Compute proc_macros in resolutions.Camille GILLOT-2/+1
2021-09-01Undo debug statementsTheodore Luo Wang-14/+1
2021-09-01Update formattingTheodore Luo Wang-1/+1
2021-09-01Add checks for a block before a unary plus. Fix failing testsTheodore Luo Wang-8/+25
2021-08-31Apply formattingTheodore Luo Wang-1/+6
2021-08-31Improve error checking on unary plusTheodore Luo Wang-0/+12
2021-09-01Auto merge of #87688 - camsteffen:let-else, r=cjgillotbors-10/+68
Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall, I believe this PR is feature-complete with regard to the RFC.
2021-08-31Rollup merge of #88450 - notriddle:notriddle/maybe_whole_expr, r=cjgillotMara Bos-2/+2
fix(rustc_parse): correct span in `maybe_whole_expr!` Fixes #87812
2021-08-30Handle let-else initializer edge case errorsCameron Steffen-0/+46
2021-08-30Add let-else to ASTCameron Steffen-10/+22
2021-08-29Auto merge of #88262 - klensy:pprust-cow, r=nagisabors-2/+2
Cow'ify some pprust methods Reduce number of potential needless de/allocations by using `Cow<'static, str>` instead of explicit `String` type.
2021-08-28fix(rustc_parse): incorrect span information for macro path exprMichael Howell-1/+1
Old error output: 3 | let _: usize = $f; | ----- ^ expected `usize`, found struct `Baz` | | | expected due to this New error output: 3 | let _: usize = $f; | ----- ^^ expected `usize`, found struct `Baz` | | | expected due to this
2021-08-28fix(rustc_parse): incorrect span information for macro block exprMichael Howell-1/+1
Old error output: = note: this warning originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info) help: wrap this expression in parentheses | 4 | break '_l $f(;) | ^ ^ New error output: = note: this warning originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info) help: wrap this expression in parentheses | 4 | break '_l ($f); | ^ ^
2021-08-27Point at unclosed delimiters as part of the primary MultiSpanEsteban Kuber-3/+18
Both the place where the parser encounters a needed closed delimiter and the unclosed opening delimiter are important, so they should get the same level of highlighting in the output.
2021-08-27Path remapping: Make behavior of diagnostics output dependent on presence of ↵Michael Woerister-1/+1
--remap-path-prefix.
2021-08-27Introduce `~const`Deadbeef-26/+20
- [x] Removed `?const` and change uses of `?const` - [x] Added `~const` to the AST. It is gated behind const_trait_impl. - [x] Validate `~const` in ast_validation. - [ ] Add enum `BoundConstness` to the HIR. (With variants `NotConst` and `ConstIfConst` allowing future extensions) - [ ] Adjust trait selection and pre-existing code to use `BoundConstness`. - [ ] Optional steps (*for this PR, obviously*) - [ ] Fix #88155 - [ ] Do something with constness bounds in chalk
2021-08-25Use if-let guards in the codebaseLéo Lanteri Thauvin-41/+38
2021-08-25Convert some functions to return Cow<'static,str> instead of String to ↵klensy-2/+2
reduce potential reallocations
2021-08-24Auto merge of #87739 - Aaron1011:remove-used-attrs, r=wesleywiserbors-1/+43
Remove `Session.used_attrs` and move logic to `CheckAttrVisitor` Instead of updating global state to mark attributes as used, we now explicitly emit a warning when an attribute is used in an unsupported position. As a side effect, we are to emit more detailed warning messages (instead of just a generic "unused" message). `Session.check_name` is removed, since its only purpose was to mark the attribute as used. All of the callers are modified to use `Attribute.has_name` Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed used' attribute is implemented by simply not performing any checks in `CheckAttrVisitor` for a particular attribute. We no longer emit unused attribute warnings for the `#[rustc_dummy]` attribute - it's an internal attribute used for tests, so it doesn't mark sense to treat it as 'unused'. With this commit, a large source of global untracked state is removed.
2021-08-22Fix more “a”/“an” typosFrank Steffahn-1/+1
2021-08-22Fix typos “a”→“an”Frank Steffahn-9/+9
2021-08-21Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`Aaron Hill-1/+43
Instead of updating global state to mark attributes as used, we now explicitly emit a warning when an attribute is used in an unsupported position. As a side effect, we are to emit more detailed warning messages (instead of just a generic "unused" message). `Session.check_name` is removed, since its only purpose was to mark the attribute as used. All of the callers are modified to use `Attribute.has_name` Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed used' attribute is implemented by simply not performing any checks in `CheckAttrVisitor` for a particular attribute. We no longer emit unused attribute warnings for the `#[rustc_dummy]` attribute - it's an internal attribute used for tests, so it doesn't mark sense to treat it as 'unused'. With this commit, a large source of global untracked state is removed.
2021-08-18Remove box syntax from rustc_parseest31-8/+7
2021-08-15Introduce hir::ExprKind::Let - Take 2Caio-1/+1
2021-08-12Use smaller spans for some structured suggestionsEsteban Kuber-39/+46
Use more accurate suggestion spans for * argument parse error * fully qualified path * missing code block type * numeric casts * E0212
2021-08-11Warn when an escaped newline skips multiple linesAnton Golov-0/+5
2021-08-08Auto merge of #87235 - poliorcetics:issue-87217-fn-quali-order, r=nagisabors-1/+34
Improve diagnostics for wrongly ordered keywords in function declaration Fix #87217 `@rustbot` label A-diagnostics T-compiler
2021-08-04Auto merge of #87026 - FabianWolff:issue-86948, r=estebankbors-4/+51
Allow labeled loops as value expressions for `break` Fixes #86948. This is currently allowed: ```rust return 'label: loop { break 'label 42; }; break ('label: loop { break 'label 42; }); break 1 + 'label: loop { break 'label 42; }; break 'outer 'inner: loop { break 'inner 42; }; ``` But not this: ```rust break 'label: loop { break 'label 42; }; ``` I have fixed this, so that the above now parses as an unlabeled break with a labeled loop as its value expression.
2021-08-03Rollup merge of #87646 - JohnTitor:fix-parser-ice, r=oli-obkYuki Okushi-3/+1
Fix a parser ICE on invalid `fn` body Fixes #87635 A better fix would add a check for `fn` body on `expected_one_of_not_found` but I haven't come up with a graceful way. Any idea? r? ```@oli-obk``` ```@estebank```
2021-08-02Rollup merge of #87659 - FabianWolff:issue-87397, r=davidtwcoCameron Steffen-8/+29
Fix invalid suggestions for non-ASCII characters in byte constants Fixes #87397.
2021-08-02Better message for invalid keyword placement in fnAlexis Bourget-1/+34
After this commit, `unsafe async fn ...` now suggests the `async unsafe` fix instead of misunderstanding the issue. This is not perfect for repeated keywords (`const async const`) and for keywords that are misplaced after `extern "some abi"` because of the way `check_fn_font_matter` works, but changing it breaks so many tests and diagnostics it has been judged too high a cost for this PR.
2021-08-01Auto merge of #87449 - matthiaskrgr:clippyy_v2, r=nagisabors-2/+1
more clippy::complexity fixes (also a couple of clippy::perf fixes)
2021-07-31Auto merge of #87662 - FabianWolff:rb-string, r=estebankbors-3/+11
Suggest `br` if the unknown string prefix `rb` is found Currently, for the following code: ```rust fn main() { rb"abc"; } ``` we issue the following suggestion: ``` help: consider inserting whitespace here | 2 | rb "abc"; | -- ``` With my changes (only in edition 2021, where unknown prefixes became an error), I get: ``` help: use `br` for a raw byte string | 2 | br"abc"; | ^^ ```
2021-07-31Require parentheses to avoid confusions around labeled break and loop ↵Fabian Wolff-4/+51
expressions
2021-07-31Suggest `br` if the unknown string prefix `rb` is foundFabian Wolff-3/+11
2021-07-31Fix invalid suggestions for non-ASCII characters in byte constantsFabian Wolff-8/+29
2021-07-30Auto merge of #86754 - estebank:use-multispans-more, r=varkorbors-10/+8
Use `multipart_suggestions` more Built on top of #86532
2021-07-31Fix a parser ICE on invalid `fn` bodyYuki Okushi-3/+1
2021-07-30Use multispan suggestions more oftenEsteban Küber-10/+8
* Use more accurate span for `async move` suggestion * Use more accurate span for deref suggestion * Use `multipart_suggestion` more often
2021-07-30Add warning when whitespace is not skipped after an escaped newline.Anton Golov-0/+6
2021-07-27Auto merge of #85305 - MarcusDunn:master, r=pnkfelixbors-1/+1
Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490), im pretty new to the whole thing so any pointers are greatly appreciated.
2021-07-25clippy::filter_map_identityMatthias Krüger-2/+1
2021-07-24fix code to suggest `;` on parse errorElliot Bobrow-57/+57
2021-07-18Auto merge of #87242 - JohnTitor:rollup-t9rmwpo, r=JohnTitorbors-1/+8
Rollup of 8 pull requests Successful merges: - #86763 (Add a regression test for issue-63355) - #86814 (Recover from a misplaced inner doc comment) - #86843 (Check that const parameters of trait methods have compatible types) - #86889 (rustdoc: Cleanup ExternalCrate) - #87092 (Remove nondeterminism in multiple-definitions test) - #87170 (Add diagnostic items for Clippy) - #87183 (fix typo in compile_fail doctest) - #87205 (rustc_middle: remove redundant clone) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-07-18Auto merge of #87071 - inquisitivecrystal:inclusive-range, r=estebankbors-7/+42
Add diagnostics for mistyped inclusive range Inclusive ranges are correctly typed as `..=`. However, it's quite easy to think of it as being like `==`, and type `..==` instead. This PR adds helpful diagnostics for this case. Resolves #86395 (there are some other cases there, but I think those should probably have separate issues). r? `@estebank`
2021-07-18Rollup merge of #86814 - Aaron1011:inner-doc-recover, r=estebankYuki Okushi-1/+8
Recover from a misplaced inner doc comment Fixes #86781
2021-07-14Suggest a path separator if a stray colon is found in a match armFabian Wolff-15/+77
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
2021-07-11Give a helpful error for the mistake `..==`Aris Merchant-7/+42
2021-07-11Auto merge of #83918 - workingjubilee:stable-rangefrom-pat, r=joshtriplettbors-2/+0
Stabilize "RangeFrom" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern, shown as such, offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!("zero!"), 1.. => println!("positive number!"), } ``` Currently if a Rust author wants to write such a match on an integer, they must use `1..={integer}::MAX` . By allowing a "RangeFrom" style pattern, this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match, allowing for easier refactoring. This is particularly useful for instances like the above case, where different behavior on "0" vs. "1 or any positive number" is desired, and the actual MAX is unimportant. Notably, this excepts slice patterns which include half-open ranges from stabilization, as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of "in the wild" users who have deployed it to similar effect, especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match, as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns), as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs), many dating back to the feature's introduction and remaining standing to this day. However, this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is, at least, a mild diagnostic improvement in some edge cases, because before now, the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag, while also emitting the "inclusive range with no end" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of, so removing the flag request is a strict improvement. The arrival of the `J | K` "or" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example, linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692, which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the "slicing range patterns" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors, as they make some patterns much more natural to write, but there is disagreement regarding the "closed" exclusive range pattern or the "RangeTo" pattern, especially where it creates "off by one" gaps in the presence of a "catch-all" wildcard case. Also, there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on, ideally, and I think it would be reasonable to consider such a blocker to stabilizing this feature, but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the "point" of the feature, at least from my view, is to make it easier to omit wildcard matches: a pattern with such an "open" match produces an irrefutable match and does not need the wild card case, making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles, given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656, but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still, as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this, and given "approved provisionally by lang team without an RFC", I believe this might require an RFC before it can land? Unsure of procedure here, on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`
2021-07-08Rollup merge of #86932 - rylev:fix-ice-86895, r=estebankYuki Okushi-1/+7
Fix ICE when misplaced visibility cannot be properly parsed Fixes #86895 The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted. The resulting error isn't quite as nice as when the visibility is parsed properly, but I'm not sure which error to prioritize here. Displaying both errors might be too confusing. r? ```@estebank```
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 15:42:45 +0000