rust-lang / rust-lang/rust-analyzer

Do not activate `test` feature

Open
#7,225 15 comments 41 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

S-actionable
Dominant language
Rust
Stars
16.9k
Forks
2.2k
Avg merge
1d 12h
Merged PRs (30d)
72

Description

Hello!

Right now, I believe Rust Analyzer hard codes activating test as a feature. This works well for writing tests, but has the unfortunate side effect that it's difficult to have any cfgs in the rest of a codebase, which should only be active during test.

In my specific usecase, I'm working on an opengl application, and i'd like to make a "HeadlessContext". I use it like this:

#[cfg(test)]
type Gl = HeadlessContext;

#[cfg(not(test))]
type Gl = Context; // the real opengl

Right now, in the above program, Rust Analyzer will infer in all code (outside of test) that I am using HeadlessContext, not Context, which leads to false positive errors (and false negative non-errors).

I don't think the solution to this problem is really that easy though -- if RA simply allowed me to turn off test as a condition, then writing Unit Tests would suddenly get much harder, since i would no longer have access to the RA in such a context. A bit hacky, but a solution where cfg(test) on modules is accepted, but cfg(test) on non-modules is not would fix this usecase, but seems very shaky and perhaps confusing to users.

Thank you for all the hard work on this excellent library! What do you think of the above?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No file or test is named in the issue. Start by locating Rust Analyzer's logic that activates the test feature and read the 15-comment discussion for the intended trade-off between production cfg evaluation and unit-test support. Done means a settled behavior that avoids false diagnostics for non-test code without removing useful test context.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.