Without arbitrary self types, the self type could never refer to the method type
parameters, so this wasn't a problem; but with arbitrary self types, it can.
This fixes the crash from #6668; but it doesn't make method resolution work for
these methods.
It's very useful when `pub` is equivalent to "this is crate's public
API", let's enforce this!
Ideally, we should enforce it for local `cargo test`, and only during
CI, but that needs https://github.com/rust-lang/cargo/issues/5034.
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 <arifrroktim@gmail.com>
- 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
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 <frazar@users.noreply.github.com>
* 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
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 <oxalicc@pm.me>
5968: Lookup ADT and associated type names for chalk debugging / tweak chalk interner r=flodiebold a=nathanwhit
This PR improves the chalk program writing integration by looking up the names for ADTs and associated types, making the output much more readable.
There are also a few small changes to the interner, which gives some nice performance improvements. We clone `Ty`s and `ProgramClause`s relatively often in chalk, so wrapping them in `Arc`s is a perf win. This takes the time for performing type inference on the rust-analyzer codebase from 40s to 33s on my machine.
Co-authored-by: Nathan Whitaker <nathan.whitaker01@gmail.com>
5682: Add an option to disable diagnostics r=matklad a=popzxc
As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.
This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.
There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502
This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
