r271544 - [docs] Add a limitations section to SourceBasedCodeCoverage.rst

Vedant Kumar via cfe-commits cfe-commits at lists.llvm.org
Mon Jun 6 08:52:33 PDT 2016


> On Jun 4, 2016, at 6:28 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> 
> On Thu, Jun 2, 2016 at 10:19 AM, Vedant Kumar via cfe-commits <cfe-commits at lists.llvm.org> wrote:
> Author: vedantk
> Date: Thu Jun  2 12:19:45 2016
> New Revision: 271544
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=271544&view=rev
> Log:
> [docs] Add a limitations section to SourceBasedCodeCoverage.rst
> 
> Modified:
>     cfe/trunk/docs/SourceBasedCodeCoverage.rst
> 
> Modified: cfe/trunk/docs/SourceBasedCodeCoverage.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SourceBasedCodeCoverage.rst?rev=271544&r1=271543&r2=271544&view=diff
> ==============================================================================
> --- cfe/trunk/docs/SourceBasedCodeCoverage.rst (original)
> +++ cfe/trunk/docs/SourceBasedCodeCoverage.rst Thu Jun  2 12:19:45 2016
> @@ -165,9 +165,9 @@ A few final notes:
>    indexed profiles. To combine profiling data from multiple runs of a program,
>    try e.g:
> 
> -.. code-block:: console
> +  .. code-block:: console
> 
> -    % llvm-profdata merge -sparse foo1.profraw foo2.profdata -o foo3.profdata
> +      % llvm-profdata merge -sparse foo1.profraw foo2.profdata -o foo3.profdata
> 
>  Format compatibility guarantees
>  ===============================
> @@ -184,3 +184,20 @@ Format compatibility guarantees
>  * There is a third format in play: the format of the coverage mappings emitted
>    into instrumented binaries. Tools must retain **backwards** compatibility
>    with these formats. These formats are not forwards-compatible.
> +
> +Drawbacks and limitations
> +=========================
> +
> +* Code coverage does not handle stack unwinding in the presence of uncaught
> +  exceptions precisely.
> 
> I think it's more accurate to say "thrown exceptions" (or just "exceptions") instead of "uncaught exceptions". The latter could be interpreted as meaning that if the exception is caught later (in a caller of f), then the result might still be precise.

Fair point, I've dropped the "uncaught" modifier.


> Also setjmp/longjmp can affect things too, no?

Yes, I mentioned this in r271902. Feel free to change up the wording!

thanks
vedant


> 
> -- Sean Silva
>  
> Consider the following function:
> +
> +  .. code-block:: cpp
> +
> +      int f() {
> +        may_throw();
> +        return 0;
> +      }
> +
> +  If the function ``may_throw()`` propagates an exception into ``f``, the code
> +  coverage tool may mark the ``return`` statement as executed even though it is
> +  not.
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



More information about the cfe-commits mailing list