nitpick, following f0dcfe008d58053e52c51b10e51c58eae27c1f0b

In code comment, typo + replace OSL_FAIL by SAL_WARN

Change-Id: I77fc643f86a2711ce68aa206923ac7913ab81e12
Reviewed-on: https://gerrit.libreoffice.org/58374
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

1 files changed, 2 insertions, 2 deletions

diff --git a/include/svx/svdmodel.hxx b/include/svx/svdmodel.hxx
index 19cb27a3570b..127bf4ed985f 100644
--- a/include/svx/svdmodel.hxx
+++ b/include/svx/svdmodel.hxx
@@ -167,14 +167,14 @@ private:
     // hidden/non-existing maAllIncarnatedObjects.
     // SdrObject::SdrObject uses impAddIncarnatedSdrObjectToSdrModel, while SdrObject::~SdrObject
     // uses impRemoveIncarnatedSdrObjectToSdrModel.
-    // There are two places which may trigger OSL_FAIL warnings:
+    // There are two places which may trigger SAL_WARN warnings:
     // - impRemoveIncarnatedSdrObjectToSdrModel when the to-be-removed SdrObject is not member of SdrModel
     // - SdrModel::~SdrModel after all SdrObjects *should* be cleaned-up.
     // SdrModel::~SdrModel will also - for convenience - Free the non-deleted SdrObjects if there
     // are any.
     // Using std::unordered_set will use quasi constant access times, so this watchdog will not
     // be expensive. Nonetheless, only use with debug code. It may be seductive to use this in
-    // product code, too, especially if it will indeed trigger - but it's intention is clearly
+    // product code, too, especially if it will indeed trigger - but its intention is clearly
     // to find/identify MemoryLeaks caused by SdrObjects
     friend void impAddIncarnatedSdrObjectToSdrModel(const SdrObject& rSdrObject, SdrModel& rSdrModel);
     friend void impRemoveIncarnatedSdrObjectToSdrModel(const SdrObject& rSdrObject, SdrModel& rSdrModel);