docs(misc): eliminate several Sphinx warnings

docs/config_builder.py

@@ -12,21 +12,32 @@ import sys
 import re
 
 base_path = os.path.dirname(__file__)
-dst_config = os.path.join(base_path, 'lv_conf.h')
+dest_config = os.path.join(base_path, 'lv_conf.h')
 src_config = os.path.abspath(os.path.join(
     base_path,
     '..',
     'lv_conf_template.h'
 ))
-disabled_option_re = re.compile(r'^\s*#define\s+\w+\s+(\b0\b)')
+disabled_option_re = re.compile(r'^\s*#define\s+(LV_(?:USE|FONT)_\w+)\s+(\b0\b)')
+
+leave_disabled_list = [
+    'LV_USE_PROFILER',
+    'LV_FONT_SIMSUN_14_CJK',
+    'LV_FONT_SIMSUN_16_CJK',
+    'LV_USE_DRAW_ARM2D_SYNC',
+    'LV_USE_NATIVE_HELIUM_ASM',
+]
+# Note:  The 2 LV_FONT_SIMSUN_... fonts have been deprecated in favor of
+# LV_FONT_SOURCE_HAN_SANS_SC_14_CJK and LV_FONT_SOURCE_HAN_SANS_SC_16_CJK.
 
 
-def run(c_path=None):
+def run(output_cfg_path=None):
-    global dst_config
+    global dest_config
+    enable_content_macro_processed = False
     os.chdir(base_path)
 
-    if c_path is not None:
+    if output_cfg_path is not None:
-        dst_config = c_path
+        dest_config = output_cfg_path
 
     with open(src_config, 'r') as f:
         data = f.read()
@@ -34,39 +45,34 @@ def run(c_path=None):
     lines = data.split('\n')
 
     for i, line in enumerate(lines):
-        if 'LV_USE_PROFILER' in line:
+        if not enable_content_macro_processed:
-            continue
+            if line.startswith('#if 0'):
-
+                line = line.replace('#if 0', '#if 1')
-        # These 2 fonts have been deprecated in favor of
+                lines[i] = line
-        # LV_FONT_SOURCE_HAN_SANS_SC_14_CJK and
+                enable_content_macro_processed = True
-        # LV_FONT_SOURCE_HAN_SANS_SC_16_CJK.
+        else:
-        if 'LV_FONT_SIMSUN_14_CJK' in line:
-            continue
-
-        if 'LV_FONT_SIMSUN_16_CJK' in line:
-            continue
-
-        if 'LV_USE' in line or ('LV_FONT' in line and '#define' in line):
             match = disabled_option_re.search(line)
             if match:
-                # Replace '0' with '1' without altering any other part of line.
+                # Except for these...
-                # Set `j` to index where '0' was found.
+                if match[1] in leave_disabled_list:
-                j = match.regs[1][0]
+                    continue
-                # Surgically insert '1' in place of '0'.
+                else:
-                lines[i] = line[:j] + '1' + line[j + 1:]
+                    # ...replace '0' with '1' without altering any other part of line.
-        elif line.startswith('#if 0'):
+                    # Set `j` to index where '0' was found.
-            line = line.replace('#if 0', '#if 1')
+                    j = match.regs[2][0]
-            lines[i] = line
+                    # Surgically insert '1' in place of '0'.  Strings are immutable.
+                    line = line[:j] + '1' + line[j + 1:]
+                    lines[i] = line
 
     data = '\n'.join(lines)
 
-    with open(dst_config, 'w') as f:
+    with open(dest_config, 'w') as f:
         f.write(data)
 
 
 def cleanup():
-    if os.path.exists(dst_config):
+    if os.path.exists(dest_config):
-        os.remove(dst_config)
+        os.remove(dest_config)
 
 
 if __name__ == '__main__':

docs/src/details/auxiliary-modules/observer/observer.rst

@@ -17,7 +17,7 @@ This implementation consists of:
 
 :Subjects:   (in global memory or heap) are "logic packages", each containing the
              value being "observed" and its type (integer (``int32_t``), a string, a
-             pointer, an :cpp:type:`lv_color_t`, a :cpp_type:`float`, or a group);
+             pointer, an :cpp:type:`lv_color_t`, a ``float``, or a group);
 
 :Observers:  (zero or more per Subject, always dynamically-allocated) are always
              attached to exactly one Subject, and provide user-defined notifications
@@ -579,7 +579,7 @@ Increments the subject's value by `step`, clamped between `min` and `max`.
 
 For example:
 
-:cpp:expr:`lv_obj_add_subject_increment_event(button1, subject1, LV_EVENT_CLICKED, 5, -10, 80);`
+:cpp:expr:`lv_obj_add_subject_increment_event(button1, subject1, LV_EVENT_CLICKED, 5, -10, 80)`
 
 This will increment `subject1` by 5 when `button1` is clicked.
 The resulting value will be constrained to the range -10 to 80.

docs/src/details/auxiliary-modules/translation.rst

@@ -13,15 +13,19 @@ LVGL supports two ways of handling translations:
 
 - ``lv_translation``: A simpler yet more flexible solution that allows adding translations statically or dynamically. This is the method documented here.
 
+
+
 Add Translations
 ****************
 
+
 Static Translations
 -------------------
 
 If most translations are known at compile time, they can be defined using string arrays:
 
 .. code-block:: c
+
     static const char * languages[] = {"en", "de", "es", NULL};
     static const char * tags[] = {"tiger", "lion", "rabbit", "elephant", NULL};
     static const char * translations[] = {
@@ -35,6 +39,7 @@ If most translations are known at compile time, they can be defined using string
 
 This method uses only a little extra RAM, as only the pointers to the strings are stored.
 
+
 Dynamic Translations
 --------------------
 
@@ -42,6 +47,8 @@ If translations are only available at runtime (e.g., from files, serial ports, o
 
 This approach involves memory allocation. See the example at the bottom of this page for reference.
 
+
+
 Select a Language
 *****************
 
@@ -51,6 +58,8 @@ Once translations are registered, use:
 
 to set the current language. The parameter must match one of the language names provided during registration.
 
+
+
 Translate Strings
 *****************
 
@@ -62,9 +71,11 @@ To retrieve a translation for a given tag, use:
 These return a translated string which can be used with widgets:
 
 .. code-block:: c
+
     lv_label_set_text(label, lv_tr("settings"));
     lv_dropdown_set_options(dd, lv_tr("color_list"));
 
+
 Fallbacks
 ---------
 
@@ -75,6 +86,8 @@ If the tag is not found at all, the tag itself will be used as a fallback as wel
 
 .. _lv_translation_example:
 
+
+
 Example
 *******
 
@@ -82,5 +95,7 @@ Example
 
 .. _lv_translation_api:
 
+
+
 API
 ***

docs/src/details/auxiliary-modules/xml/api.rst

@@ -21,7 +21,7 @@ Overview
 While Widgets can have complex ``set``/``get`` APIs, Components are very simple.
 
 When their XML is converted to a C file, only a ``create`` function is generated,
-where all the ``<prop>``s are arguments. For example:
+where all the ``<prop>``\ s are arguments. For example:
 
 .. code-block:: xml
 
@@ -43,7 +43,7 @@ used to modify any widget in the component, but no dedicated API functions are g
 Referencing properties
 ----------------------
 
-``<prop>``s are simply forwarded to widget or component APIs.
+``<prop>``\ s are simply forwarded to widget or component APIs.
 For example, if a component has ``<prop name="button_label" type="string"/>``,
 it can be used in a label as ``<lv_label text="$button_label"/>``.
 
@@ -109,7 +109,7 @@ Parameters
 ----------
 
 Some properties take multiple parameters. For example:
-:cpp:expr:`lv_label_set_bind_text(label, subject, "%d °C");`
+:cpp:expr:`lv_label_set_bind_text(label, subject, "%d °C")`
 
 It's described as:
 
@@ -168,15 +168,15 @@ Enum values are ignored in export; the names are used and resolved by the compil
 XML parsers must handle mapping enum names to C enums.
 
 <element>
---------
+---------
 
 Also exclusive to Widgets, elements define sub-widgets or internal structures
 (e.g., chart series, dropdown list, tab views).
 
 They support ``<arg>`` and ``<prop>``:
 
-- ``<arg>``s are required and used for creation.
+- ``<arg>``\ s are required and used for creation.
-- ``<prop>``s are optional and mapped to setters.
+- ``<prop>``\ s are optional and mapped to setters.
 
 Elements are referenced as ``<widget-element>`` in views.
 
@@ -290,7 +290,7 @@ Generates:
     void my_widget_set_item_color(lv_obj_t * parent, int32_t index, lv_color_t color);
 
 access="custom"
-~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~
 
 Used to describe any custom API functions with a custom name.
 "custom" elements can have only arguments and no `type` so they are pure setters.

docs/src/details/auxiliary-modules/xml/events.rst

@@ -35,7 +35,7 @@ User-defined functions can be called like this:
     </view>
 
 When the XML is loaded at runtime, the callback name needs to be mapped to a function using
-:cpp:expr:`lv_xml_register_event_cb("my_callback_1", an_event_handler);`.
+:cpp:expr:`lv_xml_register_event_cb("my_callback_1", an_event_handler)`.
 
 The callback should follow the standard LVGL event callback signature:
 ``void an_event_handler(lv_event_t * e);``

docs/src/details/auxiliary-modules/xml/index.rst

@@ -28,6 +28,5 @@ XML - Declarative UI
     subjects
     animations
     translation
-    license
+    test
-
     license

docs/src/details/auxiliary-modules/xml/screens.rst

@@ -24,6 +24,7 @@ It's also possible to define ``<screen permanent="true">`` which
 will make the screen created automatically.
 
 
+
 Usage
 *****
 
@@ -60,6 +61,9 @@ This example illustrates a screen in XML:
             </selector_container>
         </view>
     </screen>
+
+
+
 Screen Load and Create events
 *****************************
 

docs/src/details/auxiliary-modules/xml/styles.rst

@@ -22,19 +22,19 @@ In the ``<styles>`` section, styles and their properties can be defined like thi
         border_width="2px"
         border_color="0xff0000"/>
 
-Styles can be referenced like this in the ``<view>``:
+Styles can be referenced like this in the ``<view>``\ :
 
 .. code-block:: xml
 
     <view>
         <lv_slider value="20">
              <style name="main"/>
-             <style name="red" selector"knob"/>
+             <style name="red" selector="knob"/>
              <style name="blue" selector="knob focused"/>
         </lv_slider>
     </view>
 
-As shown in the example, parts and states can be set as ``selector``.
+As shown in the example, parts and states can be set as ``selector``\ .
 
 
 Local Styles

docs/src/details/auxiliary-modules/xml/test.rst

@@ -9,10 +9,10 @@ Overview
 
 The XML test module is a powerful and flexible way to define functional UI tests.
 
-Test XML files are similar to components but are wrapped in a `<test>` tag and consist of two main parts:
+Test XML files are similar to components but are wrapped in a ``<test>`` tag and consist of two main parts:
 
-- **UI Definition**: Use `<styles>`, `<consts>`, and `<view>` to define how the UI should look. This is identical to how `<component>`s are structured.
+- **UI Definition**: Use ``<styles>``, ``<consts>``, and ``<view>`` to define how the UI should look. This is identical to how ``<component>``\ s are structured.
-- **Test Steps**: Encapsulated in a `<steps>` tag, these define the actions and assertions for the test.
+- **Test Steps**: Encapsulated in a ``<steps>`` tag, these define the actions and assertions for the test.
 
 Step Types
 ----------
@@ -103,7 +103,7 @@ and then call :cpp:expr:`lv_xml_test_run_next(slowdown)` as many times.
 
 :cpp:expr:`lv_xml_test_run_next()` returns ``true`` if the given step passed, or ``false`` if it failed.
 
-Finally, call :cpp:expr:`lv_xml_test_run_stop();` to clean up and exit testing mode.
+Finally, call :cpp:expr:`lv_xml_test_run_stop()` to clean up and exit testing mode.
 
 
 Getting the Test Results

docs/src/details/auxiliary-modules/xml/translation.rst

@@ -9,24 +9,27 @@ Overview
 
 The XML translation module allows defining and using translated strings directly within XML files.
 
+
+
 Usage
 *****
 
 Example XML translation definition:
 
 .. code-block:: xml
+
     <translations languages="en de hu">
       <translation tag="dog"       en="The dog"     de="Der Hund"       hu="A kutya"/>
       <translation tag="cat"       en="The cat"     de="Die Katze"      hu="A cica"/>
       <translation tag="snake"     en="A snake"     de="Eine Schlange"  hu="A kígyó"/>
     </translations>
 
-In the root `<translations>` tag, the `languages` attribute defines the available languages,
+In the root ``<translations>`` tag, the ``languages`` attribute defines the available languages,
 e.g., ``languages="en de hu"``. Language codes are free-form, but ISO-style codes are recommended.
 
-Each `<translation>` defines a `tag`, which acts as the lookup key, and attributes for each language.
+Each ``<translation>`` defines a ``tag``, which acts as the lookup key, and attributes for each language.
 
-Translations may be omitted—:ref:`Fallbacks <xml_translations_fallback>` will be applied when needed.
+Translations may be omitted—:ref:``Fallbacks <xml_translations_fallback>`` will be applied when needed.
 
 To register XML translations:
 
@@ -35,15 +38,20 @@ To register XML translations:
 
 Multiple XML sources can be registered; they will be merged and searched collectively.
 
+
+
 Usage in XML
 ************
 
-Some widget properties support a `*-translated` suffix to refer to translation tags. For example:
+Some widget properties support a ``*-translated`` suffix to refer to translation tags. For example:
 
 .. code-block:: xml
+
     <lv_label text-translated="dog"/>
 
-This sets the label's text to the translated string for `"dog"`.
+This sets the label's text to the translated string for ``"dog"``.
+
+
 
 More Details
 ************

examples/widgets/arclabel/index.rst

@@ -2,5 +2,5 @@ Simple Arc Label
 ----------------
 
 .. lv_example:: widgets/arclabel/lv_example_arclabel_1
-:language: c
+    :language: c
-:description: A simple example to demonstrate the use of an arc label.
+    :description: A simple example to demonstrate the use of an arc label.

src/draw/sw/blend/neon/lv_blend_neon.h

@@ -16,6 +16,8 @@ extern "C" {
 
 #include "../../../../lv_conf_internal.h"
 
+#if LV_USE_DRAW_SW_ASM == LV_DRAW_SW_ASM_NEON
+
 #ifdef LV_DRAW_SW_NEON_CUSTOM_INCLUDE
 #include LV_DRAW_SW_NEON_CUSTOM_INCLUDE
 #endif
@@ -1294,6 +1296,8 @@ static inline lv_result_t lv_argb8888_blend_normal_to_argb8888_mix_mask_opa_neon
  *      MACROS
  **********************/
 
+#endif /* #if LV_USE_DRAW_SW_ASM == LV_DRAW_SW_ASM_NEON */
+
 #ifdef __cplusplus
 } /*extern "C"*/
 #endif