Re: [Intel-gfx] [PATCH v2] kernel-doc: rename the kernel-doc directive 'functions' to 'identifiers'

[Markus Heiser]

Am 29.10.19 um 01:31 schrieb Changbin Du:

But is it, really? I agree with Jon about the distinction between None
and '' being confusing.


Here python is different from C. Both empty string and None are False in python.
Note such condition is common in python.


The one is a empty string str(''), its bool('') value is False.

| >>> type(''), bool('')
| (, False)

The other is a NoneType, its bool(None) value is False.

| >>> type(None), bool(None)
| (, False)

None often used like NULL (pointer). E.g if a function does not give an explicit 
return value, the returned value is None.


| >>> def foo():
| ... pass
| ...
| >>> print(foo())
| None


-- Markus --

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Markus Heiser]

> Am 12.12.2017 um 16:23 schrieb Daniel Vetter :
> 
>>> Thanks for your patch, but similar fix is already merged here [1]
>>> 
>>> Michal
>>> 
>>> [1] 
>>> https://cgit.freedesktop.org/drm-tip/commit/?id=006c23327f8de8575508c458131b304188d426f7
>> 
>> 
>> Thanks for pointing out. I miss the ":doc: GuC-specific firmware loader"
>> fix in that patch (doc section was removed in d9e2e0143c).  Can you or
>> someone else from @intel fix this also?
> 
> I've rebased the patch from you to only take that remaining part.
> 
> Thanks for fixing this.
> -Daniel

Thanks for picking this up [1].

[1] https://cgit.freedesktop.org/drm/drm-intel/commit/?id=0132a1a5

-- Markus --
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Markus Heiser]

> Am 12.12.2017 um 13:05 schrieb Michal Wajdeczko <michal.wajdec...@intel.com>:
> 
> On Tue, 12 Dec 2017 12:38:37 +0100, Markus Heiser <markus.hei...@darmarit.de> 
> wrote:
> 
>> With commit d9e2e0143c the 'GuC-specific firmware loader' doc
>> section was removed from intel_guc_loader.c without a
>> replacement.  So lets remove it from the Kernel-doc::
>> 
>>  .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
>> :doc: GuC-specific firmware loader
>> 
>> With commit e8668bbcb0 intel_guc_loader.c was renamed to to
>> intel_guc_fw.c and to name just one, intel_guc_init_hw() was
>> renamed to intel_guc_fw_upload(). Since we get errors in the
>> Sphinx build like:
>> 
>> - Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c
>> 
>> Change the kernel-doc directive from intel_guc_loader.c to
>> intel_guc_fw.c
>> 
>> Signed-off-by: Markus Heiser <markus.hei...@darmarit.de>
>> ---
> 
> Thanks for your patch, but similar fix is already merged here [1]
> 
> Michal
> 
> [1] 
> https://cgit.freedesktop.org/drm-tip/commit/?id=006c23327f8de8575508c458131b304188d426f7


Thanks for pointing out. I miss the ":doc: GuC-specific firmware loader"
fix in that patch (doc section was removed in d9e2e0143c).  Can you or
someone else from @intel fix this also?

Thanks!

 -- Markus --



> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Markus Heiser]

With commit d9e2e0143c the 'GuC-specific firmware loader' doc
section was removed from intel_guc_loader.c without a
replacement.  So lets remove it from the Kernel-doc::

  .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
 :doc: GuC-specific firmware loader

With commit e8668bbcb0 intel_guc_loader.c was renamed to to
intel_guc_fw.c and to name just one, intel_guc_init_hw() was
renamed to intel_guc_fw_upload(). Since we get errors in the
Sphinx build like:

- Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c

Change the kernel-doc directive from intel_guc_loader.c to
intel_guc_fw.c

Signed-off-by: Markus Heiser <markus.hei...@darmarit.de>
---
 Documentation/gpu/i915.rst | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee03..e94d3ac 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,7 @@ GuC
 GuC-specific firmware loader
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
-   :doc: GuC-specific firmware loader
-
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
 
 GuC-based command submission
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/11] dma-buf: Introduce fence_get_rcu_safe()

[Markus Heiser]

Am 23.09.2016 um 14:59 schrieb Daniel Vetter :

>> 
>> /**
>> - * fence_put - decreases refcount of the fence
>> - * @fence:  [in]fence to reduce refcount of
>> + * fence_get_rcu_safe  - acquire a reference to an RCU tracked fence
>> + * @fence:  [in]pointer to fence to increase refcount of
>> + *
>> + * Function returns NULL if no refcount could be obtained, or the fence.
>> + * This function handles acquiring a reference to a fence that may be
>> + * reallocated within the RCU grace period (such as with 
>> SLAB_DESTROY_BY_RCU),
>> + * so long as the caller is using RCU on the pointer to the fence.
>> + *
>> + * An alternative mechanism is to employ a seqlock to protect a bunch of
>> + * fences, such as used by struct reservation_object. When using a seqlock,
>> + * the seqlock must be taken before and checked after a reference to the
>> + * fence is acquired (as shown here).
>> + *
>> + * The caller is required to hold the RCU read lock.
> 
> Would be good to cross reference the various fence_get functions a bit
> better in the docs. But since the docs aren't yet pulled into the rst/html
> output, that doesn't matter that much

Hi Daniel ... I'am working on ;-)

* 
http://return42.github.io/sphkerneldoc/linux_src_doc/include/linux/fence_h.html

-- Markus --
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/20] drm/doc: Fix more kerneldoc/sphinx warnings

[Markus Heiser]

Am 11.08.2016 um 10:23 schrieb Jani Nikula :

> On Thu, 11 Aug 2016, Jani Nikula  wrote:
>> On Tue, 09 Aug 2016, Daniel Vetter  wrote:
>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>>> b/drivers/gpu/drm/i915/intel_audio.c
>>> index d32f586f9c05..85389cdd0bec 100644
>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>> @@ -51,10 +51,10 @@
>>>  * related registers. (The notable exception is the power management, not
>>>  * covered here.)
>>>  *
>>> - * The struct i915_audio_component is used to interact between the graphics
>>> - * and audio drivers. The struct i915_audio_component_ops *ops in it is
>>> + * The struct _audio_component is used to interact between the 
>>> graphics
>>> + * and audio drivers. The struct _audio_component_ops @ops in it is
>> 
>> Please prefer " foo" over "struct ". The former makes the
>> struct be part of the link text.
> 
> Mmmh, the kernel-doc highlighting code should probably learn about "
> foo" spread to two lines.

my 2cent thoughts: the kernel-doc syntax is weak and ambiguous. This
remains mainly in tagging only with a start-tag or only with a end-tag 
e.g:

* sectioning:   "Return:" --> end-tag just ":"
* fields:   "@arg1:"  --> better
* highlight/ref: start tag [@%$&] / no end tag

the most ambiguous is highlighting, known quirks [1]. I tried 
to improve it in the kernel-doc parser, but haven't found
any good or better reg-expressions yet.

We had this already and I won't restart the discussion, just
to remember: In my POC I tried to handle this quirks by distinguish
*vintage* from *modern* markup and in my first attempt I dropped the
kernel-doc highlight markups from the *modern* syntax.

My conclusion is, conceptional we should not try to extend the wacky
kernel-doc syntax supporting e.g. multi-line markup constructs, 
particularly if there is a reST markup available.

We should only improve the kernel-doc reg-expressions e.g. not to have
*fails-match* for highlighting on common things like a e-mail addresses.

[1] http://www.spinics.net/lists/linux-media/msg103145.html

-- Markus --
> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

[Markus Heiser]

Am 20.07.2016 um 13:27 schrieb Daniel Vetter <daniel.vet...@ffwll.ch>:

> On Wed, Jul 20, 2016 at 12:55 PM, Markus Heiser
> <markus.hei...@darmarit.de> wrote:
>> Hi Daniel, hi Mauro,
>> 
>> Am 19.07.2016 um 17:32 schrieb Daniel Vetter <daniel.vet...@ffwll.ch>:
>> 
>>> On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter <daniel.vet...@ffwll.ch> 
>>> wrote:
>>>> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
>>>> <markus.hei...@darmarit.de> wrote:
>>>>> 
>>>>> Am 19.07.2016 um 13:42 schrieb Daniel Vetter <daniel.vet...@ffwll.ch>:
>>>>> 
>>>>>> Unfortunately warnings generated after parsing in sphinx can end up
>>>>>> with entirely bogus files and line numbers as sources. Strangely for
>>>>>> outright errors this is not a problem. Trying to convert warnings to
>>>>>> errors also doesn't fix it.
>>>>>> 
>>>>>> The only way to get useful output out of sphinx to be able to root
>>>>>> cause the error seems to be enabling keep_warnings, which inserts
>>>>>> a System Message into the actual output. Not pretty at all, but I
>>>>>> don't really want to fix up core rst/sphinx code, and this gets the job
>>>>>> done meanwhile.
>>>>> 
>>>>> Hi Daniel,
>>>>> 
>>>>> may I misunderstood you. Did you really get more or different warnings
>>>>> if you include them into the output with "keep_warnings"?
>>>>> 
>>>>> The documentation says:
>>>>> 
>>>>> "Regardless of this setting, warnings are always written
>>>>>  to the standard error stream when sphinx-build is run."
>>>>> 
>>>>> see http://www.sphinx-doc.org/en/stable/config.html#confval-keep_warnings
>>>>> 
>>>>> Or did you not run "make cleandoc" first? Sphinx caches the doctrees
>>>>> and reports markup errors only when you rebuild the cache.
>>>>> The cache is also rebuild if you touch one of the source, e.g.
>>>>> the drivers/gpu/drm/drm_crtc.c or the rst-file where the drm_crtc.c
>>>>> is referred by a kernel-doc directive .. these dependence sometimes
>>>>> confuse me .. when I missed log messages, I clean the cache e.g. by
>>>>> target cleandocs.
>>>> 
>>>> Yes I'm aware that sphinx it's WARNINGs when doing a partially
>>>> rebuild, this is something entirely different. I didn't get more or
>>>> less warnings this way, but keep_warning = True seems to be the only
>>>> way to get reasonable information about them. Without that I get
>>>> warnings (for included kernel-doc) where the source file is the .rst
>>>> file that pulls in the kernel doc, and the line number is entirely
>>>> bogus (often past the end of the containing .rst).
>>>> 
>>>> With this I can at least then open the generated .html file, search
>>>> for the System Message and figure out (by looking at the surrounding
>>>> context) where the error really is from.
>>>> 
>>>> Strangely this only happens for WARNING. If I manged the kerneldoc
>>>> enough to upset sphinx into generating an ERROR, the line numbers and
>>>> source files are correct.
>>>> 
>>>> See patch 2/2 in this series for examples of such WARNINGs: Mostly
>>>> it's unbalanced _ * or `` annotations that confuse sphinx/rst a bit.
>>>> If you want to play around with the gpu sphinx conversion to reproduce
>>>> these locall you can grab the drm-intel-nightly branch from
>>>> 
>>>> https://cgit.freedesktop.org/drm-intel
>>>> 
>>>> It already includes Jon's latest docs-next branch.
>>> 
>>> btw, I couldn't check this since I didn't figure out how to intercept
>>> the parsed rst tree and view it, but I think what's going on is:
>>> - The source file for these warnings is .rst file containing the
>>> kernel-doc directive. This seems to be a bug in sphinx/docutils since
>>> we never use that file name when appending files at all.
>>> - The line number looks like it's just counting the inserted
>>> kernel-doc lines as part of the containing .rst file. At least
>>> changing the content_offset in nested_parse seems to suggest that this
>>> is the start line (e.g. adding 10k there results in all bogus WARNING
>>

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Fix more kerneldoc/sphinx warnings

[Markus Heiser]

Am 20.07.2016 um 14:20 schrieb Mauro Carvalho Chehab <mche...@s-opensource.com>:

> Em Tue, 19 Jul 2016 14:36:50 +0200
> Daniel Vetter <dan...@ffwll.ch> escreveu:
> 
>> On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
>>> These are the leftovers I could only track down using keep_warnings =
>>> True. For some of them we might want to update our style guide on how
>>> to reference structures and constants, not sure ...
>>> 
>>> Cc: Markus Heiser <markus.hei...@darmarit.de>
>>> Cc: Jonathan Corbet <cor...@lwn.net>
>>> Cc: linux-...@vger.kernel.org
>>> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>  
>> 
>> Aside: With this and the latest docs-next branch from Jon it's possible to
>> compile test doc changes (e.g. with git rebase -x) using:
>> 
>> $ make IGNORE_DOCBOOKS=1 SPHINXOPTS=-W htmldocs
> 
> Unfortunately, we'll not get rid of Sphinx warnings any time soon.
> 
> The Sphinx function parser is really broken, even on version 1.4.5.
> 
> Every time Sphinx finds a typedef argument or return value, like here:
> 
>   ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, 
> size_t idx, int offset, u8 __user * buf, size_t len);
> 
> It produces a very ugly noisy warning:
> 
> ./drivers/media/dvb-core/dvb_ringbuffer.h:149: WARNING: Error when parsing 
> function declaration.
> If the function has no return type:
>  Error in declarator or parameters and qualifiers
>  Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 8]
>ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t 
> idx, int offset, u8 __user * buf, size_t len)
>^
> If the function has a return type:
>  Error in declarator or parameters and qualifiers
>  If pointer to member declarator:
>Invalid definition: Expected '::' in pointer to member (function). [error 
> at 37]
>  ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, 
> size_t idx, int offset, u8 __user * buf, size_t len)
>  -^
>  If declarator-id:
>Invalid definition: Expecting "," or ")" in parameters_and_qualifiers, got 
> "*". [error at 102]
>  ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, 
> size_t idx, int offset, u8 __user * buf, size_t len)
>  
> --^
> 

Aaargh ... it seems you are right. 

There is a discussion about function overloading and identifiers

  https://github.com/sphinx-doc/sphinx/issues/2682#issuecomment-229515888

If we use the C-domain ("..c:function::"  instead of ".. cpp:function::")
this error did not expire. But using the C-domain has other drawbacks, we
discussed with ioctl.

May be it is better to switch to the c-domain and try to handle 
these drawbacks ... I don't know.

> I guess that the problem is because Sphinx tries to generate a CPP like
> function name for cross-ref, and such parser is unable to handle typedef
> arguments. IMHO, this is broken by design.

by design? 

-- Markus --

> 
> 
> Thanks,
> Mauro

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

[Markus Heiser]

Hi Daniel, hi Mauro,

Am 19.07.2016 um 17:32 schrieb Daniel Vetter <daniel.vet...@ffwll.ch>:

> On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
>> <markus.hei...@darmarit.de> wrote:
>>> 
>>> Am 19.07.2016 um 13:42 schrieb Daniel Vetter <daniel.vet...@ffwll.ch>:
>>> 
>>>> Unfortunately warnings generated after parsing in sphinx can end up
>>>> with entirely bogus files and line numbers as sources. Strangely for
>>>> outright errors this is not a problem. Trying to convert warnings to
>>>> errors also doesn't fix it.
>>>> 
>>>> The only way to get useful output out of sphinx to be able to root
>>>> cause the error seems to be enabling keep_warnings, which inserts
>>>> a System Message into the actual output. Not pretty at all, but I
>>>> don't really want to fix up core rst/sphinx code, and this gets the job
>>>> done meanwhile.
>>> 
>>> Hi Daniel,
>>> 
>>> may I misunderstood you. Did you really get more or different warnings
>>> if you include them into the output with "keep_warnings"?
>>> 
>>> The documentation says:
>>> 
>>>  "Regardless of this setting, warnings are always written
>>>   to the standard error stream when sphinx-build is run."
>>> 
>>> see http://www.sphinx-doc.org/en/stable/config.html#confval-keep_warnings
>>> 
>>> Or did you not run "make cleandoc" first? Sphinx caches the doctrees
>>> and reports markup errors only when you rebuild the cache.
>>> The cache is also rebuild if you touch one of the source, e.g.
>>> the drivers/gpu/drm/drm_crtc.c or the rst-file where the drm_crtc.c
>>> is referred by a kernel-doc directive .. these dependence sometimes
>>> confuse me .. when I missed log messages, I clean the cache e.g. by
>>> target cleandocs.
>> 
>> Yes I'm aware that sphinx it's WARNINGs when doing a partially
>> rebuild, this is something entirely different. I didn't get more or
>> less warnings this way, but keep_warning = True seems to be the only
>> way to get reasonable information about them. Without that I get
>> warnings (for included kernel-doc) where the source file is the .rst
>> file that pulls in the kernel doc, and the line number is entirely
>> bogus (often past the end of the containing .rst).
>> 
>> With this I can at least then open the generated .html file, search
>> for the System Message and figure out (by looking at the surrounding
>> context) where the error really is from.
>> 
>> Strangely this only happens for WARNING. If I manged the kerneldoc
>> enough to upset sphinx into generating an ERROR, the line numbers and
>> source files are correct.
>> 
>> See patch 2/2 in this series for examples of such WARNINGs: Mostly
>> it's unbalanced _ * or `` annotations that confuse sphinx/rst a bit.
>> If you want to play around with the gpu sphinx conversion to reproduce
>> these locall you can grab the drm-intel-nightly branch from
>> 
>> https://cgit.freedesktop.org/drm-intel
>> 
>> It already includes Jon's latest docs-next branch.
> 
> btw, I couldn't check this since I didn't figure out how to intercept
> the parsed rst tree and view it, but I think what's going on is:
> - The source file for these warnings is .rst file containing the
> kernel-doc directive. This seems to be a bug in sphinx/docutils since
> we never use that file name when appending files at all.
> - The line number looks like it's just counting the inserted
> kernel-doc lines as part of the containing .rst file. At least
> changing the content_offset in nested_parse seems to suggest that this
> is the start line (e.g. adding 10k there results in all bogus WARNING
> line numbers being increased by 10k). And adding more blank lines at
> the beginning of the inserted kernel-doc rst also increases the
> reported lines. But not when inserting blank lines at the end (i.e. it
> seems like it's being reset after each directive again).

Thanks for the explanation.

> All that suggest to me this is a sphinx-internal issue, and google
> sugggests there's lots of errata around line reporting. Hence why I
> went with this. But of course a proper fix would be awesome! Just a
> bit outside of what I think I can pull off ...

It is not really a sphinx-internal issue (rather a drawback of the design).
The state machine needs a system reporter that takes the origin file
and it's line numbers as context.

I send a fix to Jon:

 
http://mid.gmane.or

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

[Markus Heiser]

Am 19.07.2016 um 13:42 schrieb Daniel Vetter <daniel.vet...@ffwll.ch>:

> Unfortunately warnings generated after parsing in sphinx can end up
> with entirely bogus files and line numbers as sources. Strangely for
> outright errors this is not a problem. Trying to convert warnings to
> errors also doesn't fix it.
> 
> The only way to get useful output out of sphinx to be able to root
> cause the error seems to be enabling keep_warnings, which inserts
> a System Message into the actual output. Not pretty at all, but I
> don't really want to fix up core rst/sphinx code, and this gets the job
> done meanwhile.

Hi Daniel,

may I misunderstood you. Did you really get more or different warnings
if you include them into the output with "keep_warnings"?

The documentation says:

  "Regardless of this setting, warnings are always written
   to the standard error stream when sphinx-build is run."

see http://www.sphinx-doc.org/en/stable/config.html#confval-keep_warnings

Or did you not run "make cleandoc" first? Sphinx caches the doctrees
and reports markup errors only when you rebuild the cache.
The cache is also rebuild if you touch one of the source, e.g.
the drivers/gpu/drm/drm_crtc.c or the rst-file where the drm_crtc.c
is referred by a kernel-doc directive .. these dependence sometimes
confuse me .. when I missed log messages, I clean the cache e.g. by 
target cleandocs.

-- Markus --
> 
> Cc: Markus Heiser <markus.hei...@darmarit.de>
> Cc: Jonathan Corbet <cor...@lwn.net>
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> Documentation/conf.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 6cc41a0555a3..a131139675cc 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -125,7 +125,7 @@ pygments_style = 'sphinx'
> #modindex_common_prefix = []
> 
> # If true, keep warnings as "system message" paragraphs in the built 
> documents.
> -#keep_warnings = False
> +keep_warnings = True
> 
> # If true, `todo` and `todoList` produce output, else they produce nothing.
> todo_include_todos = False
> -- 
> 2.8.1
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx