The limit was introduced in https://github.com/rust-lang/rust-analyzer/pull/1408#discussion_r294059044 to avoid infinite cycles but it effectively caps the number of derefs to 10. Types like `ID3D12Device14` from the `windows` crate run into this because it derefs to `ID3D12Device13`, 13 to 12 and so on. Increasing it to 20 is a quick fix; a better cycle detection method would be nicer long term.
Ensure that all the fields that rust-analyzer understands are in the
manual, they all have doc comments, and they use consistent
punctuation (`;` rather than mixing `,` and `;`).
Whilst we're here, fix the `sysroot_src` example and add 2024 as a
legal value for Rust edition.
This time, when completing the keyword (e.g. `fn` + whitespace).
The bug was actually a double-bug:
First, we did not resolve the impl in the macro-expanded file but in the real file, which of course cannot work.
Second, in analysis the whitespace was correlated with the `impl` and not the incomplete `fn`, which caused fake (where we insert an identifier after the whitespace) and real expansions to go out of sync, which failed analysis. The fix is to skip whitespaces in analysis.
the constant is wrong on some platforms (e.g., on mips64el it's 0x10, and 0x8
is RTLD_NOLOAD which makes all this functionality broken), the libc crate takes
care of those differences for us.
fallback to not setting the flag in non-glibc environments - some of them might
have support for it using a different value that we don't know about, and some
of them lack it entirely.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Improve `select_nth_unstable` documentation clarity
* Instead uses `before` and `after` variable names in the example
where `greater` and `lesser` are flipped.
* Uses `<=` and `>=` instead of "less than or equal to" and "greater
than or equal to" to make the docs more concise.
* General attempt to remove unnecessary words and be more precise. For
example it seems slightly wrong to say "its final sorted position",
since this implies there is only one sorted position for this element.
Stable Hash: Ignore all HirIds that just identify the node itself
This should provide better incremental caching, but it seems there is more to it.
These IDs also serve no purpose being in the stable hash of the item they refer to, only when referring to *another* item is it important that we hash the `HirId`. So we can at least avoid the cost during stable hashing, even if we don't benefit from it by avoiding some queries' caches from being invalidated
Unsure how to make sure we do this right by construction. Would be nice to do something type based
