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
Formula, BuildError: Update type signatures #16002
Formula, BuildError: Update type signatures #16002
Conversation
I'm looking into the new Edit: I updated the type signature for |
c0d0d14
to
c12e06f
Compare
c12e06f
to
e34a053
Compare
We're seeing type errors when building formulae that use something like `xcodebuild ..., "-arch", Hardware::CPU.arch`, since `CPU.arch` is a symbol. We've been addressing these issues by calling `#to_s` on the value but there was some talk about simply expanding the type signatures to accommodate anything that will be cast to a `String`. There's maybe still an argument to be made for doing string conversion in formulae but expanding the type signatures will resolve a number of existing type errors if we simply want to rely on implicit type casting. Past that, this also updates the type signature for `BuildError` to align with the `#system` signature changes, as we receive a type error otherwise.
e34a053
to
578c935
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Symbol looks like a good option
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah to_str
kinda sucks when you deal with explicit typing.
I'm guessing Version
might appear in a few places too.
Thanks @samford, looks good! |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?We're seeing type errors when building formulae that use something like
xcodebuild ..., "-arch", Hardware::CPU.arch
, sinceCPU.arch
is a symbol. We've been addressing these issues by calling#to_s
on the value but there was some talk about simply expanding the type signatures to accommodate anything that will be cast to aString
.There's maybe still an argument to be made for doing string conversion in formulae but expanding the type signatures will resolve a number of existing type errors if we simply want to rely on implicit type casting.
Past that, this also updates the type signature for
BuildError
to align with the#system
signature changes, as we receive a new type error otherwise.