summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
2021-09-16Re-add 71a7f8f1884b2c83eeb4a545eef16df1f2ea6476 post-revert.Felix S. Klock II-1/+4
(cherry picked from commit f26f1ed9a7208c0d928f0413cdd5f0966fa2c399)
2021-09-16Revert "Implement Anonymous{Struct, Union} in the AST"Felix S. Klock II-35/+13
This reverts commit 059b68dd677808e14e560802d235ad40beeba71e. Note that this was manually adjusted to retain some of the refactoring introduced by commit 059b68dd677808e14e560802d235ad40beeba71e, so that it could likewise retain the correction introduced in commit 5b4bc05fa57be19bb5962f4b7c0f165e194e3151 (cherry picked from commit 91feb76d133952825e3eb32bed399ec6e4bd9219)
2021-09-04Auto merge of #88598 - estebank:type-ascription-can-die-in-a-fire, r=wesleywiserbors-4/+16
Detect bare blocks with type ascription that were meant to be a `struct` literal Address part of #34255. Potential improvement: silence the other knock down errors in `issue-34255-1.rs`.
2021-09-03Auto merge of #88597 - cjgillot:lower-global, r=petrochenkovbors-2/+1
Move global analyses from lowering to resolution Split off https://github.com/rust-lang/rust/pull/87234 r? `@petrochenkov`
2021-09-03Detect bare blocks with type ascription that were meant to be a `struct` literalEsteban Kuber-4/+16
Address part of #34255. Potential improvement: silence the other knock down errors in `issue-34255-1.rs`.
2021-09-03Auto merge of #88386 - estebank:unmatched-delims, r=jackh726bors-3/+18
Point at unclosed delimiters as part of the primary MultiSpan 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. _Context: https://twitter.com/mwk4/status/1430631546432675840_
2021-09-03Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebankbors-1/+1
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in https://github.com/rust-lang/rust/pull/83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in #70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see https://github.com/rust-lang/rfcs/pull/3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to https://github.com/rust-lang/rust/pull/88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642. Fixes https://github.com/rust-lang/rust/issues/87745. cc `@cbeuw` r? `@ghost`
2021-09-01Compute proc_macros in resolutions.Camille GILLOT-2/+1
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-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`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 23:57:18 +0000