language-servers/rust-analyzer
1
0
Fork 0
mirror of https://github.com/rust-lang/rust-analyzer.git synced 2025-09-29 13:25:09 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

minor: extend source_to_def docs

Browse source
This commit is contained in:
Aleksey Kladov 2021-06-22 16:12:01 +03:00
parent fa0d568522
commit 2860f25ef3
1 changed files with 18 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

20
crates/hir/src/semantics/source_to_def.rs
View file

@ -1,6 +1,6 @@
//! Maps *syntax* of various definitions to their semantic ids. //! Maps *syntax* of various definitions to their semantic ids.
//! //!
//! This is a very interesting module, and, in some sense, can be considered a //! This is a very interesting module, and, in some sense, can be considered the
//! heart of the IDE parts of rust-analyzer. //! heart of the IDE parts of rust-analyzer.
//! //!
//! This module solves the following problem: //! This module solves the following problem:
@ -17,7 +17,7 @@
//! looking at the syntax of the function we can realise that it is a part of an //! looking at the syntax of the function we can realise that it is a part of an
//! `impl` block, but we won't be able to tell what trait function the current //! `impl` block, but we won't be able to tell what trait function the current
//! function overrides, and whether it does that correctly. For that, we need to //! function overrides, and whether it does that correctly. For that, we need to
//! go from [`ast::Fn`] to [`crate::Function], and that's exactly what this //! go from [`ast::Fn`] to [`crate::Function`], and that's exactly what this
//! module does. //! module does.
//! //!
//! As syntax trees are values and don't know their place of origin/identity, //! As syntax trees are values and don't know their place of origin/identity,
@ -68,6 +68,22 @@
//! current node. Then, `findSourceNonLocalFirDeclaration` gets `Fir` for this //! current node. Then, `findSourceNonLocalFirDeclaration` gets `Fir` for this
//! parent. Finally, `findElementIn` function traverses `Fir` children to find //! parent. Finally, `findElementIn` function traverses `Fir` children to find
//! one with the same source we originally started with. //! one with the same source we originally started with.
//!
//! One question is left though -- where does the recursion stops? This happens
//! when we get to the file syntax node, which doesn't have a syntactic parent.
//! In that case, we loop through all the crates that might contain this file
//! and look for a module whose source is the given file.
//!
//! Note that the logic in this module is somewhat fundamentally imprecise --
//! due to conditional compilation and `#[path]` attributes, there's no
//! injective mapping from syntax nodes to defs. This is not an edge case --
//! more or less every item in a `lib.rs` is a part of two distinct crates: a
//! library with `--cfg test` and a library without.
//!
//! At the moment, we don't really handle this well and return the first answer
//! that works. Ideally, we should first let the caller to pick a specific
//! active crate for a given position, and then provide an API to resolve all
//! syntax nodes against this specific crate.
use base_db::FileId; use base_db::FileId;
use hir_def::{ use hir_def::{