Commit 2021-08-18 18:52 e6fda2ac
View on Github →fix(transform_decl): fix namespace bug (#8733)
- The problem was that when writing
@[to_additive] def foo ...
every declaration used infoo
in namespacefoo
would be additivized without changing the last part of the name. This behavior was intended to translate automatically generated declarations likefoo._proof_1
. However, iffoo
contains a non-internal declarationfoo.bar
andadd_foo.bar
didn't exist yet, it would also create a declarationadd_foo.bar
additivizingfoo.bar
. - This PR changes the behavior: if
foo.bar
has the@[to_additive]
attribute (potentially with a custom additive name), then we won't create a second additive version offoo.bar
, and succeed normally. However, iffoo.bar
doesn't have the@[to_additive]
attribute, then we fail with a nice error message. We could potentially support this behavior, but it doesn't seem that worthwhile and it would require changing a couple low-level definitions that@[to_additive]
uses (e.g. by replacingname.map_prefix
so that it only maps prefixes if the name isinternal
). - So far this didn't happen in the library yet. There are currently 5 non-internal declarations
foo.bar
that are used infoo
wherefoo
has the@[to_additive]
attribute, but all of these declarations were already had an additive versionadd_foo.bar
. - These 5 declarations are
[Mon.has_limits.limit_cone, Mon.has_limits.limit_cone_is_limit, con_gen.rel, magma.free_semigroup.r, localization.r]
- This fixes the error in #8707 and resolves the Zulip thread https://leanprover.zulipchat.com/#narrow/stream/144837-PR-reviews/topic/.238707.20linter.20weirdness
- I also added some documentation / comments to the function
transform_decl_with_prefix_fun_aux
, made it non-private, and rewrote some steps.