| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Resolves 2 `cfg_attr` FIXMEs
|
| |
|
|
|
|
|
|
|
|
| |
ItemTree is per-file, so there is no unique crate associated with it.
This means that it cannot know the active CfgOptions and thus couldn't
handle `cfg_attr`.
Prepare it for `cfg_attr`s by avoiding accessing attributes.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
They were useful during initial development of the item tree, but
now just cause churn
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6016: Emit diagnostics for unresolved imports and extern crates r=jonas-schievink a=jonas-schievink
AFAIK, we don't have any major bugs in name resolution that would cause a lot of false positives here (except procedural attribute macro support and some rare issues around `#[path]` on module files), so these are *not* marked as experimental diagnostics right now.
I noticed that diagnostics in a file sometimes don't get displayed after opening, but require some edit to be performed. This seems like a preexisting issue though.
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |
|
|/ |
|
|
|