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

Persist name resolution for field names #2466

Merged
merged 16 commits into from
Dec 13, 2024
Merged

Conversation

facundominguez
Copy link
Collaborator

@facundominguez facundominguez commented Dec 12, 2024

Another step for #2169.

Also fixes #2412 by making the field names available as measures as the documentation says it should.

The main contribution of this PR is persisting name resolution of field names. They are treated much the same as the names of measures in #2464.

To get tests passing I had to stop LH from trying to qualify names at some places, which would interfere with name resolution of field names. This made me aware that much of the passes to qualify identifiers are now redundant, so I removed most of them.

An additional commit fixes name resolution for built-in data constructors and names in the logic map, which previously produced names with makeLocalLHName, and now they are constructed with makeLogicLHName. The big difference is that the later causes names to be qualified when converted to symbols. These omissions were identified when removing calls to qualifying passes.

The commit that makes showLHNameDebug the show instance for LHName is a follow up from #2456. A few error messages were impacted and there might be still a few places that aren't caught by tests.

Given that I had to remove some qualifying passes, I updated the mechanism to resolve expression aliases, which does require occurrences of expression aliases to be qualified. The name resolution pass now makes sure they are qualified.

Lastly I removed some calls to getLHNameSymbol from Bare.hs, replacing them with either lhNameToUnqualifiedSymbol or lhNameToResolvedSymbol, which defines what is the intended behavior.

@facundominguez
Copy link
Collaborator Author

I managed to remove most of the qualify passes after fixing a mistake in lhNameToResolvedSymbol.

The only pass that remains is Bare.qualifyFTycon, that first requires persisting name resolution for qualifiers.

Copy link

@sjoerdvisscher sjoerdvisscher left a comment

Choose a reason for hiding this comment

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

Looks good, mostly some whitespace to fix.

(F.dummyPos "expand-iSpecs2")
[]
(M.fromList dependencySpecs)
mySpec2 = Bare.expand rtEnv l mySpec1 where l = F.dummyPos "expand-mySpec2"

Choose a reason for hiding this comment

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

Clean-up: I think you should inline the l here.

@@ -497,8 +491,7 @@ makeSpecQual _cfg env tycEnv measEnv _rtEnv specs = SpQual

makeQualifiers :: Bare.Env -> Bare.TycEnv -> (ModName, Ms.Spec F.Symbol ty) -> [F.Qualifier]
makeQualifiers env tycEnv (modn, spec)
= fmap (Bare.qualifyTopDummy env modn)
. Mb.mapMaybe (resolveQParams env tycEnv modn)
= Mb.mapMaybe (resolveQParams env tycEnv modn)

Choose a reason for hiding this comment

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

Clean-up: remove whitespace

where
qual t es = qualifyTermExpr env name rtEnv t <$> es
qual es = expandTermExpr rtEnv <$> es

Choose a reason for hiding this comment

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

Clean-up: line-up equal signs or remove whitespace

= (v, t, e)
where
t = Bare.qualifyTop env name (F.loc t0) t0
(t0, e) = makeAssumeType allowTC embs lmap dm x mbT v def
(t, e) = makeAssumeType allowTC embs lmap dm x mbT v def

Choose a reason for hiding this comment

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

Clean-up: line up equals sign

@@ -656,7 +656,7 @@ ofBDataCtorTc env name l l' tc αs ps πs _ctor@(DataCtor _c as _ xts res) c' =
res' = Bare.ofBareType env name l (Just ps) <$> res
t0' = dataConResultTy c' αs t0 res'
_cfg = getConfig env
(yts, ot) = qualifyDataCtor (not isGadt) name dLoc (zip xs ts', t0')
(yts, ot) = (zip xs ts', t0')

Choose a reason for hiding this comment

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

Assigning a tuple to a tuple

where
lookupLHName s = Mb.fromMaybe (panic (Just (GM.fSrcSpan ldcp)) $ "unexpected symbol: " ++ show s) $ lookup s lhNameMap

Choose a reason for hiding this comment

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

Clean-up: line up equals signs

@@ -1113,10 +1099,10 @@ mkReft _ _ _ _
-------------------------------------------------------------------------------------------
makeSpecName :: Bare.Env -> Bare.TycEnv -> Bare.MeasEnv -> ModName -> GhcSpecNames
-------------------------------------------------------------------------------------------
makeSpecName env tycEnv measEnv name = SpNames
makeSpecName env tycEnv measEnv _name = SpNames

Choose a reason for hiding this comment

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

Should the _name argument be removed?

@@ -75,13 +75,13 @@ makeRTEnv env modName mySpec dependencySpecs lmap
= renameRTArgs $ makeRTAliases tAs $ makeREAliases eAs
where
tAs = [ t | (_, s) <- specs, t <- Ms.aliases s ]

Choose a reason for hiding this comment

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

Clean-up: remove whitepsace here too.

expandMeasure :: Bare.Env -> ModName -> BareRTEnv -> BareMeasure -> BareMeasure
expandMeasure env name rtEnv m = m
expandMeasure :: BareRTEnv -> BareMeasure -> BareMeasure
expandMeasure rtEnv m = m
{ msSort = RT.generalize <$> msSort m

Choose a reason for hiding this comment

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

Clean-up: remove whitespace

@facundominguez facundominguez merged commit 26384c4 into develop Dec 13, 2024
4 checks passed
@facundominguez facundominguez deleted the fd/resolve-field-names branch December 13, 2024 14:50
@facundominguez
Copy link
Collaborator Author

Thanks @sjoerdvisscher!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Scope and meaning of fields in data specs
2 participants