Skip to content

Use build_info_path in load_build_info, update TOML parsing logic #825

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

Merged
merged 4 commits into from
Sep 23, 2024

Conversation

palinatolmach
Copy link
Collaborator

@palinatolmach palinatolmach commented Sep 20, 2024

This PR addresses the

  File "/Users/palina/rv/kontrol/src/kontrol/solc.py", line 501, in load_build_info
    build_info = json.loads(max(build_info_files, key=os.path.getmtime).read_text())
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: max() iterable argument is empty

error which occurs if the project uses a non-default build_info_path in foundry.toml:

[profile.default]
src = "src"
out = "out"
libs = ["lib"]
build_info_path = 'artifacts/build-info'
extra_output = ['storageLayout']

[profile.kontrol-properties]
out = 'out-kontrol-properties'

In addition, it also updates the profile function in foundry.py so that if the key is not defined in the current profile but it is set in the default profile, the default value (and not an empty string) is used:

    @property
    def profile(self) -> dict[str, Any]:
        profile_name = os.getenv('FOUNDRY_PROFILE', default='default')

        current_profile = self._toml['profile'].get(profile_name, {})
        default_profile = self._toml['profile'].get('default', {})

        return {**default_profile, **current_profile}

@palinatolmach palinatolmach changed the title WIP: use build_info_path in load_build_info Use build_info_path in load_build_info, update TOML parsing logic Sep 23, 2024
@palinatolmach palinatolmach self-assigned this Sep 23, 2024
@palinatolmach palinatolmach marked this pull request as ready for review September 23, 2024 05:37
@palinatolmach palinatolmach added the bug Something isn't working label Sep 23, 2024
@palinatolmach palinatolmach merged commit e111624 into master Sep 23, 2024
12 checks passed
@palinatolmach palinatolmach deleted the fix-compilation-unit-bug branch September 23, 2024 07:00
palinatolmach added a commit to runtimeverification/k that referenced this pull request Oct 10, 2024
… active (#4657)

Follow up to runtimeverification/kontrol#825.

In Foundry, when parsing TOML config files, values set in a default
profile (e.g., `[prove.default]` in `kontrol.toml`) are inherited by
other profiles unless they are explicitly overridden in those profiles,
which helps avoid redefining shared configuration settings between
profiles ([Foundry docs](https://book.getfoundry.sh/config/)). We'd like
to support the same behavior in `kontrol.toml`.

Similarly to a change made in
runtimeverification/kontrol#825 to the
`foundry.toml` parsing, this PR enforces reading the values set in both
active and `default` profiles and using the default ones for values that
are not set in the active profile. This PR also adds a
`test_prove_legacy_profiles` test that ensures that both `default` and
active profile's values are used.

I do realise, however, that this behavior (other profiles inheriting
from `default`) is non-standard, so I'd appreciate any feedback on this
PR. Maybe it'd be better if I added another parameter in `get_profile`
that would enable this behavior only if the function is called by
Kontrol?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants