| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
5969: Propose module name completion options r=jonas-schievink a=SomeoneToIgnore
<img width="539" alt="image" src="https://user-images.githubusercontent.com/2690773/92663009-cb0aec00-f308-11ea-9ef5-1faa91518031.png">
Currently traverses the whole file set every time we try to complete the module, as discussed in https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/mod.3C.7C.3E.20completion
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| | | | |
|
| |/ / |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`hir` should know nothing about URLs, markdown and html. It should
only be able to:
* resolve stringy path from documentation
* generate canonical stringy path for a def
In contrast, link rewriting should not care about semantics of paths
and names resolution, and should be concern only with text mangling
bits.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Doc comments *are* attributes, so there's no reason to have two crates
here.
|
| |\ |
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4776: Do a weekly minor publish to crates.io r=matklad a=pksunkara
This is the same system I set up on Chalk repo.
Every week it creates a new minor version, pushes it to github and then deploys it to crates.io.
Co-authored-by: Pavan Kumar Sunkara <[email protected]>
|
| | | | |
|
| | | | |
|
| | |/ |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5823: Don't underline function definition if self is &mut r=Nashenas88 a=matklad
The self is right there, and is already underlined, so it makes little
sense to emit even more underlines.
before:
after:
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
| |
| |
| |
| | |
The self is right there, and is already underlined, so it makes little
sense to emit even more underlines.
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
We might want to provide more efficient impls for check if usages
exist, limiting the search, filtering and cancellation, so let's
violate YAGNI a bit here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Main one: instead of adding a parameter to function to handle special
case, make the caller handle it.
Second main one: make sure that function does a reasonable thing.
`highlight_def` picks a color for def, *regardless* of the context
the def is use. Feeding an info from the call-site muddies the
responsibilities here.
Minor smells, flagging the function as having space for improvement in
the first place:
* many parameters, some of which are set as constants on most
call-sites (introduce severalfunction instad)
* boolean param (add two functions instead)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
