about summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
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```
2021-07-08Rollup merge of #86812 - FabianWolff:recover-dyn-mut, r=petrochenkovYuki Okushi-1/+21
Recover from `&dyn mut ...` parse errors Consider this example: ```rust fn main() { let r: &dyn mut Trait; } ``` This currently leads to: ``` error: expected one of `!`, `(`, `;`, `=`, `?`, `for`, lifetime, or path, found keyword `mut` --> src/main.rs:2:17 | 2 | let r: &dyn mut Trait; | ^^^ expected one of 8 possible tokens error: aborting due to previous error ``` However, especially for beginners, I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes, I get a help message, and the parser even recovers: ``` error: `mut` must precede `dyn` --> test.rs:2:12 | 2 | let r: &dyn mut Trait; | ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn` error[E0405]: cannot find trait `Trait` in this scope --> test.rs:2:21 | 2 | let r: &dyn mut Trait; | ^^^^^ not found in this scope error: aborting due to 2 previous errors ```
2021-07-07Fix ICE when misplaced visibility cannot be properly parsedRyan Levick-1/+7
2021-07-06rename rust_2021_token_prefixes to rust_2021_prefixes_incompatible_syntaxRyan Levick-2/+2
2021-07-06rust_2021_token_prefixesRyan Levick-2/+2
2021-07-06Rename reserved_prefix lint to reserved_prefixesRyan Levick-2/+2
2021-07-02Recover from a misplaced inner doc commentAaron Hill-1/+8
Fixes #86781
2021-07-02Recover from `&dyn mut ...` parse errorsFabian Wolff-1/+21
2021-06-26No reserved_prefix suggestion in proc macro call_site.Mara Bos-11/+13
2021-06-26Rename 'bad prefix' to 'unknown prefix'.Mara Bos-5/+5
2021-06-26Check the span's edition for the reserved prefixes.Mara Bos-15/+16
2021-06-26Improve comments for reserved prefixes.Mara Bos-1/+4
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
2021-06-26Add migration lint for reserved prefixes.Mara Bos-7/+16
2021-06-26Fix note in reserved prefix error.Mara Bos-1/+1
2021-06-26Add machine applicable suggestion to unknown prefix error.Mara Bos-5/+4
2021-06-26Reserve prefixed identifiers and string literals (RFC 3101)lrh2000-1/+31
This commit denies any identifiers immediately followed by one of three tokens `"`, `'` or `#`, which is stricter than the requirements of RFC 3101 but may be necessary according to the discussion at [Zulip]. [Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/reserved.20prefixes/near/238470099
2021-06-26Auto merge of #86586 - Smittyvb:https-everywhere, r=petrochenkovbors-1/+1
Use HTTPS links where possible While looking at #86583, I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation, there are a few other HTTP links that are used by CI that are changed to HTTPS. Notes: - I didn't change any to or in licences - Some links don't support HTTPS :( - Some `http` links were dead, in those cases I upgraded them to their new places (all of which used HTTPS)
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 00:19:00 +0000