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

incompatible_always_check_depset_elements: depset: depset(direct=...) constructor does not check element validity #10313

Closed
alandonovan opened this issue Nov 26, 2019 · 2 comments
Labels
incompatible-change Incompatible/breaking change

Comments

@alandonovan
Copy link
Contributor

alandonovan commented Nov 26, 2019

The depset(direct=...) constructor that we have been recently migrating users towards does not apply the same element validity checks as the legacy depset([...]) constructor. Consequently one can insert mutable items such as structs and tuples containing lists:

x = [1, 2, 3]
s = depset(direct = [(x,)])
print(s)  # 'depset([([1, 2, 3],)])'

x.append(4) 
print(s) # 'depset([([1, 2, 3, 4],)])'

The fix is to apply the same checks as done by the legacy constructor, but this is a breaking change. The new check will thus be behind a flag called --incompatible_always_check_depset_elements.

@laurentlb
Copy link
Contributor

Can you check if s = depset([(x,)]) behaves correctly? This is the notation most people have been using. Also, please check what happens with the --incompatible_disable_depset_items flag.

I suspect this migration should be a blocker for #9017.

@alandonovan
Copy link
Contributor Author

Without the flag, depset([(x,)]) reports an error if and only if x is (or contains) a mutable value. With the flag, the expression succeeds even if x is (or contains) a mutable value. I could not see any difference between Blaze at tip and the previous release of Blaze, which is encouraging.

@laurentlb laurentlb changed the title depset: depset(direct=...) constructor does not check element validity incompatible_always_check_depset_elements: depset: depset(direct=...) constructor does not check element validity Nov 27, 2019
bazel-io pushed a commit that referenced this issue Feb 25, 2020
…rlark-hashable.

All other subclasses of analysis.ConfiguredTarget were already marked as @immutable in 13abce5. There are several starlark files using InputFileConfiguredTarget in a depset which breaks when --incompatible_always_check_depset_elements is flipped unless the class is marked @immutable.

See also: #10313

PiperOrigin-RevId: 297103804
luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this issue Sep 4, 2022
    Fixes bazelbuild/bazel#10313

    RELNOTES: The flag `--incompatible_always_check_depset_elements` is enabled by default.
    PiperOrigin-RevId: 297852167
luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this issue Sep 4, 2022
…arlark-hashable.

    All other subclasses of analysis.ConfiguredTarget were already marked as @immutable in bazelbuild/bazel@13abce5. There are several starlark files using InputFileConfiguredTarget in a depset which breaks when --incompatible_always_check_depset_elements is flipped unless the class is marked @immutable.

    See also: bazelbuild/bazel#10313

    PiperOrigin-RevId: 297103804
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
incompatible-change Incompatible/breaking change
Projects
None yet
Development

No branches or pull requests

5 participants