<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in deprecated-flags-and-options.cpp</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>9da697e1 - Reland &quot;[analyzer] Deprecate the unused &apos;analyzer-opt-analyze-nested-blocks&apos; cc1 flag&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp#9da697e1</link>
        <description>Reland &quot;[analyzer] Deprecate the unused &apos;analyzer-opt-analyze-nested-blocks&apos; cc1 flag&quot;It was previously reverted by 8406839d1926486de900c7cabeea9f841bd3edf2.---This flag was introduced byhttps://github.com/llvm/llvm-project/commit/6818991d7165f68fe196922d9e5c6648dd57cc47    commit 6818991d7165f68fe196922d9e5c6648dd57cc47    Author: Ted Kremenek &lt;kremenek@apple.com&gt;    Date:   Mon Dec 7 22:06:12 2009 +0000  Add clang-cc option &apos;-analyzer-opt-analyze-nested-blocks&apos; to treat  block literals as an entry point for analyzer checks.The last reference was removed by this commit:https://github.com/llvm/llvm-project/commit/5c32dfc5fb1cfcff8ae3671284e17daa8da3a188    commit 5c32dfc5fb1cfcff8ae3671284e17daa8da3a188    Author: Anna Zaks &lt;ganna@apple.com&gt;    Date:   Fri Dec 21 01:19:15 2012 +0000  [analyzer] Add blocks and ObjC messages to the call graph.  This paves the road for constructing a better function dependency graph.  If we analyze a function before the functions it calls and inlines,  there is more opportunity for optimization.  Note, we add call edges to the called methods that correspond to  function definitions (declarations with bodies).Consequently, we should remove this dead flag.However, this arises a couple of burning questions. - Should the `cc1` frontend still accept this flag - to keep   tools/users passing this flag directly to `cc1` (which is unsupported,   unadvertised) working. - If we should remain backward compatible, how long? - How can we get rid of deprecated and obsolete flags at some point?Reviewed By: martongDifferential Revision: https://reviews.llvm.org/D126067

            List of files:
            /llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp</description>
        <pubDate>Tue, 14 Jun 2022 08:22:37 +0000</pubDate>
        <dc:creator>Balazs Benics &lt;balazs.benics@sigmatechnology.se&gt;</dc:creator>
    </item>
<item>
        <title>ffe7950e - Reland &quot;[analyzer] Deprecate `-analyzer-store region` flag&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp#ffe7950e</link>
        <description>Reland &quot;[analyzer] Deprecate `-analyzer-store region` flag&quot;I&apos;m trying to remove unused options from the `Analyses.def` file, thenmerge the rest of the useful options into the `AnalyzerOptions.def`.Then make sure one can set these by an `-analyzer-config XXX=YYY` styleflag.Then surface the `-analyzer-config` to the `clang` frontend;After all of this, we can pursue the tablegen approach describedhttps://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488In this patch, I&apos;m proposing flag deprecations.We should support deprecated analyzer flags for exactly one release. Inthis case I&apos;m planning to drop this flag in `clang-16`.In the clang frontend, now we won&apos;t pass this option to the cc1frontend, rather emit a warning diagnostic reminding the users aboutthis deprecated flag, which will be turned into error in clang-16.Unfortunately, I had to remove all the tests referring to this flag,causing a mass change. I&apos;ve also added a test for checking this warning.I&apos;ve seen that `scan-build` also uses this flag, but I think we shouldremove that part only after we turn this into a hard error.Reviewed By: martongDifferential Revision: https://reviews.llvm.org/D126215

            List of files:
            /llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp</description>
        <pubDate>Tue, 14 Jun 2022 07:20:41 +0000</pubDate>
        <dc:creator>Balazs Benics &lt;balazs.benics@sigmatechnology.se&gt;</dc:creator>
    </item>
<item>
        <title>07b4a6d0 - [analyzer] Deprecate the unused &apos;analyzer-opt-analyze-nested-blocks&apos; cc1 flag</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp#07b4a6d0</link>
        <description>[analyzer] Deprecate the unused &apos;analyzer-opt-analyze-nested-blocks&apos; cc1 flagThis flag was introduced byhttps://github.com/llvm/llvm-project/commit/6818991d7165f68fe196922d9e5c6648dd57cc47    commit 6818991d7165f68fe196922d9e5c6648dd57cc47    Author: Ted Kremenek &lt;kremenek@apple.com&gt;    Date:   Mon Dec 7 22:06:12 2009 +0000  Add clang-cc option &apos;-analyzer-opt-analyze-nested-blocks&apos; to treat  block literals as an entry point for analyzer checks.The last reference was removed by this commit:https://github.com/llvm/llvm-project/commit/5c32dfc5fb1cfcff8ae3671284e17daa8da3a188    commit 5c32dfc5fb1cfcff8ae3671284e17daa8da3a188    Author: Anna Zaks &lt;ganna@apple.com&gt;    Date:   Fri Dec 21 01:19:15 2012 +0000  [analyzer] Add blocks and ObjC messages to the call graph.  This paves the road for constructing a better function dependency graph.  If we analyze a function before the functions it calls and inlines,  there is more opportunity for optimization.  Note, we add call edges to the called methods that correspond to  function definitions (declarations with bodies).Consequently, we should remove this dead flag.However, this arises a couple of burning questions. - Should the `cc1` frontend still accept this flag - to keep   tools/users passing this flag directly to `cc1` (which is unsupported,   unadvertised) working. - If we should remain backward compatible, how long? - How can we get rid of deprecated and obsolete flags at some point?Reviewed By: martongDifferential Revision: https://reviews.llvm.org/D126067

            List of files:
            /llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp</description>
        <pubDate>Fri, 10 Jun 2022 11:09:37 +0000</pubDate>
        <dc:creator>Balazs Benics &lt;balazs.benics@sigmatechnology.se&gt;</dc:creator>
    </item>
<item>
        <title>d50d9946 - [analyzer] Deprecate `-analyzer-store region` flag</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp#d50d9946</link>
        <description>[analyzer] Deprecate `-analyzer-store region` flagI&apos;m trying to remove unused options from the `Analyses.def` file, thenmerge the rest of the useful options into the `AnalyzerOptions.def`.Then make sure one can set these by an `-analyzer-config XXX=YYY` styleflag.Then surface the `-analyzer-config` to the `clang` frontend;After all of this, we can pursue the tablegen approach describedhttps://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488In this patch, I&apos;m proposing flag deprecations.We should support deprecated analyzer flags for exactly one release. Inthis case I&apos;m planning to drop this flag in `clang-16`.In the clang frontend, now we won&apos;t pass this option to the cc1frontend, rather emit a warning diagnostic reminding the users aboutthis deprecated flag, which will be turned into error in clang-16.Unfortunately, I had to remove all the tests referring to this flag,causing a mass change. I&apos;ve also added a test for checking this warning.I&apos;ve seen that `scan-build` also uses this flag, but I think we shouldremove that part only after we turn this into a hard error.Reviewed By: martongDifferential Revision: https://reviews.llvm.org/D126215

            List of files:
            /llvm-project-15.0.7/clang/test/Analysis/deprecated-flags-and-options.cpp</description>
        <pubDate>Fri, 10 Jun 2022 10:57:15 +0000</pubDate>
        <dc:creator>Balazs Benics &lt;balazs.benics@sigmatechnology.se&gt;</dc:creator>
    </item>
</channel>
</rss>
