aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_ty/src
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge #6350bors[bot]2020-10-261-126/+123
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 6350: Make IncorrectDiagnostic match rustc by copying rustc's code. r=popzxc a=ArifRoktim This closes #6343 and closes #6345. The old algorithm which used a `DetectedCase` enum, didn't match how rustc thinks of cases. Some inputs can be interpreted as more than 1 case depending on the situation. For example, to rustc: - `ABCD`: Can be both camel case and upper snake case - `X86_64`: Can be both camel case and upper snake case I could've made `detect_case` return a collection of `DetectedCase` and then modified the other code as such, but I think using the same code rustc uses is simpler and a surefire way to achieve the same diagnostics as rustc. Co-authored-by: Arif Roktim <[email protected]>
| * Make IncorrectDiagnostic match rustc by copying rustc's code.Arif Roktim2020-10-251-126/+123
| |
* | Get rid of FAKE_PLACEHOLDERFlorian Diebold2020-10-251-8/+9
|/ | | | | The lifetime placeholder can be replaced by the static lifetime, and for array sizes we should just be using a concrete const.
* Improve Chalk debuggingFlorian Diebold2020-10-231-7/+23
| | | | | | - add panic context for the trait goal if CHALK_DEBUG is set - print the Chalk program even if we're panicking - log goal/solution while TLS is still set
* Merge #6319bors[bot]2020-10-222-3/+34
|\ | | | | | | | | | | | | | | 6319: Properly identify camel cased acronyms as UpperCamelCase r=popzxc a=ArifRoktim This closes #6305. Co-authored-by: Arif Roktim <[email protected]>
| * Properly identify camel cased acronyms as UpperCamelCaseArif Roktim2020-10-212-3/+34
| |
* | Merge #6307bors[bot]2020-10-211-0/+18
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | 6307: Add whitelist of safe intrinsics r=frazar a=frazar This PR should fix #5996, where intrinsic operations where all marked as unsafe. I'm rather new to this codebase, so I might be doing something *very* wrong. Please forgive me! In particular, I'm not sure how to "check that we are in extern `rust-intrinsics`" as mentioned [in this comment](https://github.com/rust-analyzer/rust-analyzer/issues/5996#issuecomment-709234802). Co-authored-by: Francesco Zardi <[email protected]>
| * Move safe intrinsic testsFrancesco Zardi2020-10-211-0/+18
| |
* | Add descriptions for diagnostics parseable by xtaskIgor Aleksanov2020-10-191-0/+55
|/
* binary operator overload type inference: add test markRoland Ruckerbauer2020-10-142-0/+6
|
* Implement binary operator overloading type inferenceRoland Ruckerbauer2020-10-133-5/+120
|
* Keep SyntaxNodePtr::range privateIgor Aleksanov2020-10-122-4/+13
|
* Replace 'if let' with 'match' in decl_check.rsIgor Aleksanov2020-10-121-30/+33
|
* Add to_upper_snake_case function to stdxIgor Aleksanov2020-10-122-4/+3
|
* Fix compilation errorIgor Aleksanov2020-10-121-2/+1
|
* Apply suggestions from code reviewIgor Aleksanov2020-10-121-2/+2
| | | Co-authored-by: Lukas Wirth <[email protected]>
* Fix code style issuesIgor Aleksanov2020-10-122-3/+7
|
* Fix issues with match arm bindingsIgor Aleksanov2020-10-121-7/+12
|
* Code style adjustmentsIgor Aleksanov2020-10-123-8/+88
|
* Make incorrect case diagnostic work inside of functionsIgor Aleksanov2020-10-122-33/+248
|
* Refactor string helpers for decl_check moduleIgor Aleksanov2020-10-121-32/+97
|
* Add diagnostics for enum names and variantsIgor Aleksanov2020-10-122-2/+147
|
* Add fix for incorrect case diagnosticIgor Aleksanov2020-10-121-1/+1
|
* Improve string helpers functionsIgor Aleksanov2020-10-121-1/+8
|
* Check structure fields to be snake_caseIgor Aleksanov2020-10-121-46/+65
|
* Add check for structure names to be CamelCaseIgor Aleksanov2020-10-122-1/+139
|
* Extract helper functions into a separate moduleIgor Aleksanov2020-10-122-29/+112
|
* Add checks for function parametersIgor Aleksanov2020-10-122-7/+94
|
* Create basic support for names case checks and implement function name case ↵Igor Aleksanov2020-10-122-3/+251
| | | | check
* Make unimplemented match variants explicitCasey Primozic2020-10-071-1/+2
|
* `todo!()` -> `unimplemented!() // FIXME` for CICasey Primozic2020-10-062-3/+5
|
* Bump chalk to use latest git to get fixCasey Primozic2020-10-062-0/+13
| | | | * Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
* Fix trait object hir formatting behind pointer and referencesLukas Wirth2020-10-061-6/+23
|
* Update chalk to 0.28.0Bram van den Heuvel2020-09-251-2/+8
|
* Bump smol_str from 0.1.16 to 0.1.17Jean SIMARD2020-09-241-1/+1
|
* Use Ty::apply instead of simple and fix method resolution.Charles Lew2020-09-163-8/+14
|
* Add a test.Charles Lew2020-09-161-0/+38
|
* Lower extern type alias as foreign opaque type.Charles Lew2020-09-161-2/+6
|
* Update chalk to 0.27 and adapt to chalk changes.Charles Lew2020-09-156-27/+96
|
* Merge #5971bors[bot]2020-09-137-53/+213
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5971: Implement async blocks r=flodiebold a=oxalica Fix #4018 @flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail: - Chalk doesn't support generator type yet. - Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 ) - The output type of async block should be known after type inference of the whole body. - We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`. - During the inference, the output type of async block can be temporary unknown and participate the later inference. `let a = async { None }; let _: i32 = a.await.unwrap();` So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type. And it really works now. Well, I still have some questions: - The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here. - Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type. Co-authored-by: oxalica <[email protected]>
| * Fix type walking about type of async blockoxalica2020-09-111-14/+9
| |
| * Fix and prettify commentsoxalica2020-09-111-4/+6
| |
| * Implement async blocksoxalica2020-09-107-53/+216
| |
* | Implement box pattern inferenceJonas Schievink2020-09-121-1/+13
| |
* | Add box pattern testJonas Schievink2020-09-121-0/+25
| |
* | Rename record_field_pat to record_pat_fieldPavan Kumar Sunkara2020-09-102-4/+4
| |
* | Tweak interner for chalkNathan Whitaker2020-09-091-9/+9
| |
* | Lookup ADT and assoc. type names for chalk debugNathan Whitaker2020-09-092-5/+21
|/
* Switch to expect_test from crates.ioAleksey Kladov2020-08-219-9/+9
|
* Add type safety to diagnostic codesAleksey Kladov2020-08-181-17/+17
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-23 23:24:02 +0000