ICU-22910 Fix coverity warning in number_fluent.cpp

[mike-fabian]

See: https://unicode-org.atlassian.net/browse/ICU-22910

Checklist

• Required: Issue filed: https://unicode-org.atlassian.net/browse/ICU-22910
• Required: The PR title must be prefixed with a JIRA Issue number.
• Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
• Required: Each commit message must be prefixed with a JIRA Issue number.
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable

[markusicu]

Good catch on use-after-move, but I don't know enough about how these objects are handled.
Why do we need both the NFS move construction and also the lnfMoveHelper?
@sffc @aheninger please help.

[sffc]

LocalizedNumberFormatter inherits from NumberFormatterSettings, and it calls the move constructor of the base class. This PR is already questionable in the sense that it changes a move constructor to a move assignment.

lnfMoveHelper exists in order to deduplicate code between the move constructor and the move assignment operator. However, lnfMoveHelper assumes that the type is properly initialized: it reads and writes fields. So, I think it is only correct to call that function after a call to another constructor or assignment operator.

That said, it does appear that it's wrong to read from a moved value. However, it appears that it is legal to do this so long as the only fields read are the ones that belong to the child class and not the base class:

https://cplusplus.com/forum/beginner/187808/

It might be that cleaner code would be to change the helper function to take positional arguments of the fields from src instead of an rvalue reference that can't exist at the time the function is called.

[sffc]

LocalizedNumberFormatter inherits from NumberFormatterSettings, and it calls the move constructor of the base class. This PR is already questionable in the sense that it changes a move constructor to a move assignment.

lnfMoveHelper exists in order to deduplicate code between the move constructor and the move assignment operator. However, lnfMoveHelper assumes that the type is properly initialized: it reads and writes fields. So, I think it is only correct to call that function after a call to another constructor or assignment operator.

That said, it does appear that it's wrong to read from a moved value. However, it appears that it is legal to do this so long as the only fields read are the ones that belong to the child class and not the base class:

https://cplusplus.com/forum/beginner/187808/

It might be that cleaner code would be to change the helper function to take positional arguments of the fields from src instead of an rvalue reference that can't exist at the time the function is called.

[mike-fabian]

So if I understand this correctly, my patch here is wrong and this is a false positive by coverity. So maybe it would be good enough to mark it as a false positive for the moment?:

--- a/icu4c/source/i18n/number_fluent.cpp
+++ b/icu4c/source/i18n/number_fluent.cpp
@@ -466,6 +466,7 @@ LocalizedNumberFormatter::LocalizedNumberFormatter(LocalizedNumberFormatter&& sr
 
 LocalizedNumberFormatter::LocalizedNumberFormatter(NFS<LNF>&& src) noexcept
         : NFS<LNF>(std::move(src)) {
+    // coverity[use_after_move]
     lnfMoveHelper(std::move(static_cast<LNF&&>(src)));
 }
 

[sffc]

I'm only reporting what the code is supposed to do and that your PR changes the behavior. I don't have an opinion about whether you find other C++ code that achieves the same behavior or if you want to add a coverity suppression.