Admin message

Due to a large amount of spam we do not allow new users to create repositories, they are "external" users. If you are a new user and want to create a repository, for example for forking GHC, open a new issue on ghc/ghc using the "get-verified" issue template

DisambiguateRecordFields, not DuplicateRecordFields, should control name resolution for record updates
At the moment, the `DuplicateRecordFields` extension changes name resolution for record updates so that it is sufficient for one type (or, following #21443, one constructor) to have all the fields being updated. I claim that this behaviour should be enabled by the `DisambiguateRecordFields` extension instead. This would mean `DisambiguateRecordFields` controls all the special name lookup rules for use sites, while `DuplicateRecordFields` merely allows the definition of the same field name multiple times in the same module. (I'm assuming a post-#19461 world where the type-directed resolution is gone.) Since `DuplicateRecordFields` implies `DisambiguateRecordFields`, this change should almost always accept more programs. Concretely, the following program is rejected with ambiguity errors on the record update, but I think it should be accepted: ```hs module MS where data S = MkS { x :: Int } module MT where data T = MkT { x :: Int, y :: Int } module MU where data U = MkU { y :: Int } {-# LANGUAGE DisambiguateRecordFields #-} -- using DuplicateRecordFields here instead would work already module N where import MS import MT import MU eg r = r { x = 1, y = 1 } ``` @sheaf you may have an opinion as this relates to !8686?
issue