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

Document why 'mix xref' can give false positives #13567

Merged
merged 2 commits into from
May 20, 2024

Conversation

nathanl
Copy link
Contributor

@nathanl nathanl commented May 17, 2024

"False positives" might not be the best way to describe this case; if not, please advise.

@josevalim
Copy link
Member

Thank you. I have incorporated your changes into the existing description, so we provide an example. Let me know what you think.

@michallepicki
Copy link
Contributor

I also have been using the term "unnecessary recompilations" at work when explaining this topic like @nathanl originally did here. "False positives" does not sound right, these are real dependencies caused by (understandable) limitations in compiler's dependency tracking model/algorithm

@josevalim josevalim merged commit e71a51b into elixir-lang:main May 20, 2024
9 checks passed
@josevalim
Copy link
Member

💚 💙 💜 💛 ❤️

@josevalim
Copy link
Member

I have merged this as is. If you want to provide more context, another PR is definitely welcome!

@nathanl
Copy link
Contributor Author

nathanl commented May 20, 2024

B does not need to be recompiled, because it depends on C at runtime, but anything that depends on B at compile-time has to recompile, and that includes A.

I still find this confusing. I would picture the compiler saying:

  • C changed, but B depends on it at runtime so B doesn't need to recompile
  • A depends on B at compile time, so since B doesn't need to be recompiled, A doesn't need to be recompiled

... except it does. I was trying to have the docs explain why that's the case, but I don't really understand.

@josevalim
Copy link
Member

Anything that is called at compile-time becomes compile-time behaviour. If you only call things at runtime, then it is all runtime. But as soon as you call something at compile-time, anything in that module and what that module calls becomes compile-time, because all of them can now change the behaviour of A.

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

Successfully merging this pull request may close these issues.

None yet

3 participants