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 infooin namespacefoowould be additivized without changing the last part of the name. This behavior was intended to translate automatically generated declarations likefoo._proof_1. However, iffoocontains a non-internal declarationfoo.barandadd_foo.bardidn't exist yet, it would also create a declarationadd_foo.baradditivizingfoo.bar.
- This PR changes the behavior: if foo.barhas 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.bardoesn'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_prefixso 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.barthat are used infoowherefoohas 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.