Accidental modification of mercurial.changelog._defaultextra
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Thu Feb 1 12:56:05 UTC 2024
On 2/1/24 10:08, Manuel Jacob wrote:
> When the raw extra field on a changeset is missing, the
> mercurial.changelog.changelogrevision.extra property returns the
> _defaultextra dictionary as-is. Method
> mercurial.context.changectx.extra() returns that property as-is. The
> problem is that if someone changes the return value in this case, all
> later calls to mercurial.context.changectx.extra() on changesets
> without the raw extra field will return a dictionary containing these
> changes.
>
> To check whether the problem results in bugs in practice, I changed
> the mercurial.changelog.changelogrevision.extra property to return a
> read-only proxy to _defaultextra. Three tests fail because of this:
> https://foss.heptapod.net/mercurial/mercurial-devel/-/jobs/2253663
>
> We could change the mercurial.changelog.changelogrevision.extra
> property to always return a new dictionary. This is already the case
> if a changeset has the raw extra field.
>
> If we don’t want to return a copied dictionary when a changeset has no
> raw extra field, we would need to fix all callers that modify the
> dictionary to copy it first instead of modifying the returned
> dictionary. In the cases when the returned dictionary is already a
> copied dictionary (i.e. if the changeset has the raw extra field), it
> would be redundant.
>
> If we make it part of the contract that the returned extra dictionary
> should not be modified, should that contract be enforced somehow? We
> could return types.MappingProxyType (1) never, (2) always or (3) only
> when _defaultextra is returned.
>
> What do you think?
I think this is a pretty good catch, thanks you.
I don't believe this is reasonable to assume or enforce that caller will
not modify the returned dictionnary, and we should return a new
dictionnary in all cases. I don't expect any significant performance
impact from this.
Would you send a patch in that direction ?
--
Pierre-Yves David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20240201/8b64607a/attachment.html>
More information about the Mercurial-devel
mailing list