Skip to content

Remove Unsafe Dynflags deadcode, they don't exist any more! #4480

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

Merged

Conversation

fendor
Copy link
Collaborator

@fendor fendor commented Jan 13, 2025

I am currently reading through the ghcide code, and I noticed some supposed dead code, as unsafeDynFlags don't exist any more, setUnsafeDynFlags (and for 9.4.8) just sets a couple of Outputable IORefs, which we likely don't want/need.

Thus, just delete and see whether CI is happy.

@fendor fendor requested a review from wz1000 as a code owner January 13, 2025 11:11
@fendor fendor force-pushed the enhance/remove-unsafe-dynflags-deadcode branch 2 times, most recently from a68768a to 43eecd5 Compare January 13, 2025 12:03
@fendor fendor requested a review from soulomoon January 13, 2025 12:25
Copy link
Collaborator

@soulomoon soulomoon left a comment

Choose a reason for hiding this comment

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

Looking good at CI but, it seems effect https://gitlab.haskell.org/ghc/ghc/-/blob/59202c800f2c97c16906120ab2561f6e1556e4af/compiler/GHC/Utils/Trace.hs#L42 ?
Do we have another place passing in the setting for dynFlagsForPrinting?

@fendor fendor force-pushed the enhance/remove-unsafe-dynflags-deadcode branch from 43eecd5 to 21d12d0 Compare January 23, 2025 11:28
@fendor
Copy link
Collaborator Author

fendor commented Jan 23, 2025

All SDocs we produce, should have a reference to SDocContext which are produced from the DynFlags respective to each component. GHC was changed in the past to move towards this SDocContext instead of unsafeGlobalDynFlags to avoid this global state. Thus, not relying on these globals is more correct than before, in my opinion, even though I think we are not even using them at all.
I don't think we need to call dynFlagsForPrinting ourselves, as we are not doing anything with the produced DynFlags. In hiedb, dynFlagsForPrinting essentially creates the default DynFlags, and then uses these to initialise the SDocContext when printing AST nodes. Since it is the default DynFlags, we are effectively initialising the global variables from the default DynFlags, which I think will be the same values for the global variables any way.

Copy link
Collaborator

@soulomoon soulomoon left a comment

Choose a reason for hiding this comment

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

Thanks for the explaination, make sense to me !

@fendor fendor force-pushed the enhance/remove-unsafe-dynflags-deadcode branch from 21d12d0 to e35c378 Compare January 24, 2025 09:16
@fendor fendor enabled auto-merge (squash) January 24, 2025 09:43
@fendor fendor merged commit d75400d into haskell:master Jan 24, 2025
35 checks passed
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.

2 participants