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

lib/types: Fix coercedTo check #36638

Merged
merged 4 commits into from May 6, 2018
Merged

lib/types: Fix coercedTo check #36638

merged 4 commits into from May 6, 2018

Conversation

infinisil
Copy link
Member

Without this change

(coercedTo str toInt int).check "foo"

would evaluate to true, even though

(coercedTo str toInt int).merge {} [{ value = "foo"; }]

will throw an error because "foo" can't be coerced to an int.

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

Without this change

  (coercedTo str toInt int).check "foo"

would evaluate to true, even though

  (coercedTo str toInt int).merge {} [{ value = "foo"; }]

will throw an error because "foo" can't be coerced to an int.
@infinisil
Copy link
Member Author

So this adds both the check that coerceFunc succeeds, along with the finalType check on its result.

@infinisil
Copy link
Member Author

Ping @rycee and @Profpatsch

@Profpatsch
Copy link
Member

Can you add a succeeding/failing test pair to lib/tests/modules.sh?

@infinisil
Copy link
Member Author

@Profpatsch I added some tests. One thing I'm not sure about is whether this assert:

in assert finalType.check coerced; coerced;
is still needed, because now the check gets performed in check already, so it shouldn't even get to that point with an invalid type.

@Profpatsch
Copy link
Member

Now only the two uses of coerceFunc need to be reduced to one use somehow. Maybe with a carefully placed let-binding?

@infinisil
Copy link
Member Author

@Profpatsch Pretty sure that's not possible because the value to check occurs in the function argument to those two attributes, and the attributes can in theory be used separately anyways.

A question: I changed the name of coercedTo types slightly in the latest commit:

types.coercedTo str toInt int # "int or string convertible to it"

because it makes more sense instead of "int or string". What do you think of this naming? Maybe "int or string convertible to one" would be better or even "int or string convertible to int", which would get out of control with bigger type names.

@Profpatsch
Copy link
Member

I like the improved documentation.
But I’d really like @nbp to give his opinion on the doubling of the coerce function. We don’t use coercedTo a lot in nixpkgs, so maybe the overhead is not bad enough for it to be a blocker.

Copy link
Member

@nbp nbp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay.

  • I prefer the new wording as it explicit the manipulated type. (maybe preferred?)
  • Thanks for adding tests
  • I do not think the overhead would be a big deal at the moment, and if it is, then this can probably be separated in multiple options.

blind-review

@Profpatsch
Copy link
Member

Nice, thanks! I will merge then.

@Profpatsch Profpatsch merged commit facd515 into NixOS:master May 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants