Hello everyone,

I have started working on a tool that identifies unused imports. It uses dmd as a library.

The purpose is to have a working tool, but also to better understand what sort of information the frontend needs to output so that such tools are possible.

Up to this point, I managed to make it work with global imports (since dmdfe currently does not provide the scope hierarchy). The tool does output some false positives because semantic is destructive and some things like aliases or enums are substituted eagerly and you cannot trace their origin.

I have tested this tool with some dmd sources and have already identified unused imports·

So, if you have projects with lots of global imports you could use it to at least narrow down the list of potential unused imports.

The tool is a work in progress, so if you have any ideas for improvement feel free to ping me.

Note that the import paths used are from my machine, so you will need to update those accordingly to the files imported in your project.

RazvanN

On Tuesday, 15 August 2023 at 08:13:04 UTC, RazvanN wrote:

Not sure how relevant this is to your methods, but something I used to stumble into occasionally:

import std.format;
import std.range.primitives;
struct S {
	void toString(W)(ref W writer) if (isOutputRange!(W, char)) {
		writer.formattedWrite("ABC");
	}
}
void main() {
	S().writeln;
}

Output: ABC

import std.format;
//import std.range.primitives;
struct S {
	void toString(W)(ref W writer) if (isOutputRange!(W, char)) {
		writer.formattedWrite("ABC");
	}
}
void main() {
	S().writeln;
}

Output: S()

The latter still compiles successfully and does not issue an error for the undefined template isOutputRange. This is an issue with std.format.internal's hasToString I believe, since, because there is no toString that would successfully pass __traits(compiles) (due to the undefined symbol), it never actually attempts to call the toString, therefore the template isn't compiled at all and thus no bark for the problem. But worth mentioning IMO as an example of a process that fails to identify undefined symbols when an import is missing.

On Tuesday, 15 August 2023 at 08:13:04 UTC, RazvanN wrote:

You can handle nested import declarations without the scope. The trick would be to use a single visitor and a 2D import list, i.eImportInfo[][] imports;. The first dim matches to a scope, so when you enter a scope (BlockStmt, AggrDecl, etc) you push the local imports, and when you leave the scope, you check and pop. Styx Example, (which has same semantics as D about out-of-order decls).

This is why I think that such a tool should be integrated to the compiler.

The only way (I know of today) to detect accurately whether an alias is used is to put of flag in the ast node matching to imports. For dmd that flag would be set in Import.search().

Again another reason to integrate the tool to the compiler. There would be no need to write a driver, just a new option, let's say "--check-unused-import", and "basta".

Also I see no use case where the tool would be used with different import paths than those passed to the compiler.

On Wednesday, 16 August 2023 at 05:26:11 UTC, Basile B. wrote:

Indeed, there are solutions to this problem. Another one is to treat scope as dscanner does now (the scope is just an integer which is incremented and decremented whenever a scope is entered/left), however, I was hoping to leverage most of the existing logic in the compiler.

I am now looking for a way to integrate this in the compiler to better understand what the compiler would need to expose in order to properly implement this. I thought it would be easy, unfortunately, when dmd does symbol resolution, the search methods work on a list of imported scopes (e.g. modules or mixins) and currently there is no way to tie the imported scope to a specific import declaration/statement. DMD's code could be altered to store the import instead of the module, however, Walter has made it clear that such linting behavior will not be accepted in dmd.

RazvanN

On Wednesday, 16 August 2023 at 07:27:34 UTC, RazvanN wrote:

I know, but he should make an exception for unused imports. That's really a check that is tied to which and how sources are compiled. I find absurd to have to write a driver that will handle the exact same arguments, while that would just work if done in the compiler, to be frank.

It's another story when it's about linting something localized. But in the case we're talking about, well, you've get my point.

On Wednesday, 16 August 2023 at 05:26:11 UTC, Basile B. wrote:

To be clear the styx version had the same problem as those you mention, until that commit. The flag mentioned previously, and that is set here (implementation of search is a bit different...), did not cause any slowdown.

To conclude, I dont see how such a tool could work correctly without being integrated directly in the compiler.

On Wednesday, 16 August 2023 at 17:17:22 UTC, Basile B. wrote:

Otherwise another problem you may encounter is related to dot chains. only the LHS needs to be checked. The RHS might be resolved from the module where the LHS was found ;)