So i'll start looking into how to implement
mixed_script_confusables, whichever is easier to implement.
One immediate question i come up with, is that these two lints are kind of "accumulative", where each identifiers it meets is compared with everything it has seen before.
Since there's ongoing "parallel rustc" efforts going on, this makes me wonder how would i store the previous states.
I think i needs some instructions here again... @centril @Manish Goregaokar @Zoxc
Yeah no I wouldn't touch those yet
@Esteban Küber said he had a wip branch for some of this
Mixed script confusables is one you might want to try, the rfc suggests a way to make it super efficient
I'd just leave the confusables lint for now
Ok. I think i'll just find something else to play with for now. :slight_smile:
I have also read some code about "Adjustments to "bad style" lints" item
i think there's nothing that needs to be changed, if i've read it correctly.
Maybe we need to review the progress and tick some checkboxes in the tracking issue at some point.
A fast way to implement this is to compute skeleton for each identifier once and place the result in a hashmap as a key. If one tries to insert a key that already exists check if the two identifiers differ from each other. If so report the two confusable identifiers.
So it's based on a hashmap, and it still has parallelism issues. Maybe i'll wait for @Esteban Küber at this point.
I don't think the parser is in the critical path for compilation speed in any existing non heavily nested project, I have a few with generated code that go in the hundreds of thousands of lines and the problem there is after the ast is created
Can't this just walk the entire crate at a later point and look at all identifiers instead of carrying state around?
And for heavy meeting the problem is blowing the stack on heavy recurtion
We can but we'd also want to use this for ident not found suggestions
We do have some big rwlocks already, right?
That might not go away anytime soon
ident not found suggestions happen? I assume we can collect all idents after macro expansion.
You can't really use locks for this kind of state since it would be non-deterministic and also not tracked by incremental compilation.
ident not found suggestionshappen? I assume we can collect all idents after macro expansion.
Then you will miss the identifiers of expanded macros.
Feel free to ping me if there's any actionable item on my side. I'm happy to help push this implementation work forward.