Normalize Dialyzer PLT paths #2578
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this takes the current path formatting (which reuses compiler-specific
functions) and makes it contextual to knowing whether files exist or
not. The compiler path printing assumes all directory paths are
project-local, but PLTs only occasionally fit this description. On first
copies, they don't.
This currently yields output such as:
===> Building with 204 files in ../.cache/rebar3/rebar3_24.0.2_plt...
===> Copying ../.cache/rebar3/rebar3_24.0.2_plt to _build/default/rebar3_24.0.2_plt...
===> Checking 204 files in _build/default/rebar3_24.0.2_plt...
===> Adding 29 files to _build/default/rebar3_24.0.2_plt...
===> Doing success typing analysis...
===> Resolving files...
===> Analyzing 13 files with _build/default/rebar3_24.0.2_plt...
Whereas this patch instead allows the following formatting:
===> Dialyzer starting, this may take a while...
===> Updating plt...
===> Resolving files...
===> Updating base plt...
===> Resolving files...
===> Checking 204 files in /home/ferd/.cache/rebar3/rebar3_24.0_plt...
===> Copying /home/ferd/.cache/rebar3/rebar3_24.0_plt to /tmp/chk/_build/default/rebar3_24.0_plt...
===> Checking 204 files in _build/default/rebar3_24.0_plt...
===> Doing success typing analysis...
===> Resolving files...
===> Analyzing 2 files with _build/default/rebar3_24.0_plt...
That `Copying <from> to <dest>` message is always going to have the
`<dest>` value be absolute just because I can check whether a relative
path exists before normalizing on the absolute path, which is the
simplest way to make this work without major rework of output functions
to attach them all to the calling context to know when a path may or may
not be absolute.
Fixes erlang#2577
eproxus
approved these changes
Jun 10, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this takes the current path formatting (which reuses compiler-specific
functions) and makes it contextual to knowing whether files exist or
not. The compiler path printing assumes all directory paths are
project-local, but PLTs only occasionally fit this description. On first
copies, they don't.
This currently yields output such as:
Whereas this patch instead allows the following formatting:
That
Copying <from> to <dest>message is always going to have the<dest>value be absolute just because I can check whether a relativepath exists before normalizing on the absolute path, which is the
simplest way to make this work without major rework of output functions
to attach them all to the calling context to know when a path may or may
not be absolute.
Fixes #2577