From e86d604dc4e12fc9c494484d3f261d91e9d8b01e Mon Sep 17 00:00:00 2001 From: Tor Lillqvist Date: Thu, 30 Mar 2017 12:22:49 +0300 Subject: [PATCH] The svError case is probably not worth a SAL_WARN Also, sort the cases of that block in order of the enumerators. Change-Id: If46a4ff73d6f7d22bd54b74610eb6eebecd5aff0 --- sc/source/ui/unoobj/tokenuno.cxx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sc/source/ui/unoobj/tokenuno.cxx b/sc/source/ui/unoobj/tokenuno.cxx index 2ff0615edf56..cb767923743e 100644 --- a/sc/source/ui/unoobj/tokenuno.cxx +++ b/sc/source/ui/unoobj/tokenuno.cxx @@ -468,9 +468,10 @@ bool ScTokenConversion::ConvertToTokenSequence( const ScDocument& rDoc, default: SAL_WARN("sc", "ScTokenConversion::ConvertToTokenSequence: unhandled token type " << StackVarEnumToString(rToken.GetType())); SAL_FALLTHROUGH; - case svSep: // occurs with ocSep, ocOpen, ocClose, ocArray* case svJump: // occurs with ocIf, ocChoose + case svError: // seems to be fairly common, and probably not exceptional and not worth a warning? case svMissing: // occurs with ocMissing + case svSep: // occurs with ocSep, ocOpen, ocClose, ocArray* rAPI.Data.clear(); // no data } rAPI.OpCode = static_cast(eOpCode); //! assuming equal values for the moment