Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support for analysis of local variables #768

Open
MahatmaFatalError opened this issue Jan 8, 2022 · 8 comments
Open

Feature Request: Support for analysis of local variables #768

MahatmaFatalError opened this issue Jan 8, 2022 · 8 comments

Comments

@MahatmaFatalError
Copy link

MahatmaFatalError commented Jan 8, 2022

During https://stackoverflow.com/questions/70507647/how-to-assert-hashmap-keys-to-be-comparable-with-archunit/70509141 we needed a way to analyze local variables.

Hence, I propose to extend JavaCodeUnit https://www.archunit.org/userguide/html/000_Index.html#_domain to also support local variable definition, declaration and initialization.

@codecholeric
Copy link
Collaborator

Technically this should be doable 🙂 But notice that there once already was #227 which pretty much suggested the same I think? However, I didn't get around to it back then and nobody else was willing to tackle it either, so I eventually closed it 😞
I would be still open to it (would be necessary to analyse performance impact though and possibly make it an opt-in feature if the drain is too big, since the use case is quite specific). But, as back then I personally don't know when I can really tackle this. So any support would be highly appreciated!

@dbraun1991
Copy link

For more persons to find their way to this thread ...
https://stackoverflow.com/questions/74461422/archunit-test-sensitive-variable-naming
... ;-)

@ttho
Copy link

ttho commented Jun 14, 2024

Hello, is there still nobody working on this issue? I am willing to do so.

@ttho
Copy link

ttho commented Jul 8, 2024

Ok, at least someone likes this ;)
I actually started on it, in case someone wants to join.

@ttho
Copy link

ttho commented Jul 11, 2024

A simple solution for including local variables in the dependency checks is here: #1327
Please comment. Thanks!

ttho added a commit to ttho/ArchUnit that referenced this issue Jul 31, 2024
So far local variable instantiations were not analyzed at all, leaving gaps in the evaluation of
dependency rules. If a local variable of a certain type was instantiated in a method, but no other use of that type
was present (e.g. a method call on the type, or a field access), the dependency from the method to that type
was undetected. Here, if enabled by a new configuration property (to preserve backward compatibility and
performance), local variable instantiations add class dependencies from the surrounding method to the type of the
variable and, if that type has generic type parameters, also from the method to any concrete generic type.

Issue: TNG#768
ttho added a commit to ttho/ArchUnit that referenced this issue Aug 1, 2024
So far local variable instantiations were not analyzed at all, leaving gaps in the evaluation of
dependency rules. If a local variable of a certain type was instantiated in a method, but no other use of that type
was present (e.g. a method call on the type, or a field access), the dependency from the method to that type
was undetected. Here, if enabled by a new configuration property (to preserve backward compatibility and
performance), local variable instantiations add class dependencies from the surrounding method to the type of the
variable and, if that type has generic type parameters, also from the method to any concrete generic type.

Issue: TNG#768
Signed-off-by: Timo Thomas <[email protected]>
ttho added a commit to ttho/ArchUnit that referenced this issue Aug 1, 2024
Issue: TNG#768
Signed-off-by: Timo Thomas <[email protected]>
@ttho
Copy link

ttho commented Aug 12, 2024

@hankem , you hearted my intent to work on this. I created #1334 two weeks ago, but nobody took notice. Is there something wrong with it? Quick feedback welcome, even if it just be "need more time". Thanks.

@hankem
Copy link
Member

hankem commented Aug 12, 2024

I'm very sorry, @ttho, that you didn't get any feedback so far. It's a sad reality that there we currently don't find much time. I'll try to take a look soon™.

@olenz
Copy link

olenz commented Aug 15, 2024

This should also fix #1137.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants