Skip to content

Make FlagAssignment an opaque newtype #4849

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Oct 27, 2017
Merged

Conversation

hvr
Copy link
Member

@hvr hvr commented Oct 26, 2017

This is a refactoring abstracting FlagAssignment while retaining its
external appearance as much as possible (i.e. same Read/Show/Binary
instances etc).

Later we can attach new instances, enforce internal invariants (like
e.g. uniqueness of flagnames), switch out the internal
representation (maybe to Data.Map), etc more easily.

Please include the following checklist in your PR:

  • Patches conform to the coding conventions.
  • Any changes that could be relevant to users have been recorded in the changelog.
  • The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

@hvr hvr requested a review from phadej October 26, 2017 14:37
@hvr hvr mentioned this pull request Oct 26, 2017
4 tasks
@hvr hvr requested a review from 23Skidoo October 26, 2017 14:37
Copy link
Collaborator

@phadej phadej left a comment

Choose a reason for hiding this comment

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

Looks great, seems quite straightforward. Few comments. 👍.

@@ -26,6 +26,9 @@ module Distribution.Client.BuildReports.Anonymous (
-- showList,
) where

import Prelude (mapM)
Copy link
Collaborator

Choose a reason for hiding this comment

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

why not traverse?

@@ -15,6 +15,9 @@ module Distribution.Client.GenBounds (
genBounds
) where

import Prelude (mapM_)
Copy link
Collaborator

Choose a reason for hiding this comment

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

and traverse_

@@ -267,7 +265,7 @@ sortedFieldDescrs = sortBy (comparing fieldName) fieldDescrs

dispFlag :: (FlagName, Bool) -> Disp.Doc
dispFlag (fname, True) = Disp.text (unFlagName fname)
dispFlag (fname, False) = Disp.char '-' <> Disp.text (unFlagName fname)
dispFlag (fname, False) = Disp.char '-' PP.<> Disp.text (unFlagName fname)
Copy link
Collaborator

Choose a reason for hiding this comment

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

we have <<>>, but I don't insist.

@@ -922,10 +922,10 @@ configureFinalizedPackage verbosity cfg enabled
-- we do it here so that those get checked too
let pkg_descr = addExtraIncludeLibDirs pkg_descr0'

when (not (null flags)) $
when (flags /= mempty) $
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we have nullFlagAssignment?

@@ -898,7 +898,7 @@ configuredPackageProblems :: Platform -> CompilerInfo
-> SolverPackage UnresolvedPkgLoc -> [PackageProblem]
configuredPackageProblems platform cinfo
(SolverPackage pkg specifiedFlags stanzas specifiedDeps' _specifiedExeDeps') =
[ DuplicateFlag flag | ((flag,_):_) <- duplicates specifiedFlags ]
[ DuplicateFlag flag | ((flag,_):_) <- duplicates (PD.unFlagAssignment specifiedFlags) ] -- FIXME/TODO
Copy link
Collaborator

Choose a reason for hiding this comment

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

could you comment a little more context to TODO

@@ -419,7 +418,7 @@ planPackages verbosity comp platform mSandboxPkgInfo solver
(PackagePropertyFlags flags)
in LabeledPackageConstraint pc ConstraintSourceConfigFlagOrTarget
| let flags = configConfigurationsFlags configFlags
, not (null flags)
, flags /= mempty
Copy link
Collaborator

Choose a reason for hiding this comment

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

nullFlagAssignment

@hvr
Copy link
Member Author

hvr commented Oct 26, 2017

fwiw, turning FlagAssignment into a Map FlagName Bool will require a bit of thought, as we need to figure out how to handle the situation when conflicting flag settings collide, as right now the checks for inconsistent flag assignments are deferred.

Copy link
Member

@23Skidoo 23Skidoo left a comment

Choose a reason for hiding this comment

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

LGTM, please merge.

This is a refactoring abstracting `FlagAssignment` while retaining its
external appearance as much as possible (i.e. same Read/Show/Binary
instances etc).

Later we can attach new instances, enforce internal invariants (like
e.g. uniqueness of flagnames), switch out the internal
representation (maybe to `Data.Map`), etc more easily.
@hvr hvr force-pushed the pr/opaque-flagass branch from df78926 to 6cb6a51 Compare October 27, 2017 16:10
@hvr hvr merged commit 6cb6a51 into haskell:master Oct 27, 2017
@hvr hvr deleted the pr/opaque-flagass branch October 27, 2017 16:12
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants