The eol_at_end_of_file lint reads file content from disk and can slow down linting

[DanTup]

Splitting this out of #55281 (comment) so it doesn't get lost.

This lint reads the content in a way that appears that it can hit the disk and can be quite slow when analyzing a lot of files (or a large library):

sdk/pkg/linter/lib/src/rules/eol_at_end_of_file.dart

Line 38 in 33bdacc

var content = node.declaredFragment?.source.contents.data;

One simple option suggested by @bwilkerson was:

    var unitContext =
        context.allUnits.firstWhereOrNull((unit) => unit.unit == node);
    var content = unitContext.content;

And @scheglov:

And yes, I think registerNodeProcessors() should have access to the current LintRuleUnitContext instance. Currently it knows all units of the library, and its defining unit, but not the current.

I had a quick look at this, but I am a little confused by LinterContext.definedUnit because it seems like there is code that passes each individual unit in for it. For example this call here happens inside a loop for all units within a library (called currentUnit):

sdk/pkg/analysis_server/lib/src/services/correction/bulk_fix_processor.dart

Line 293 in 0d72db1

_computeParsedResultLint(unitContext, unitContexts);

And then currentUnit is passed as definingUnit:

sdk/pkg/analysis_server/lib/src/services/correction/bulk_fix_processor.dart

Line 557 in 0d72db1

var context = LinterContextWithParsedResults(allUnits, currentUnit);

So I wonder whether definingUnit could just be rename and repurposed as currentUnit or whether any lints really do need/want the defining unit?

[bwilkerson]

I don't know whether any of the existing lints need the defining compilation unit. If there are any, then at least some of them are likely using it to get to the imports and that logic will need to be changed to support enhanced-parts. The only way for me to find the answer to that question would be to look at all uses of definingUnit and try to determine why it's being used.