Thread

Commits

  1. Hide warnings from Python headers when using gcc-compatible compiler.

  1. apply pragma system_header to python headers

    Peter Eisentraut <peter@eisentraut.org> — 2023-11-06T12:02:15Z

    Analogous to 388e80132c (which was for Perl) but for Python, I propose 
    adding #pragma GCC system_header to plpython.h.  Without it, you get 
    tons of warnings about -Wdeclaration-after-statement, starting with 
    Python 3.12.  (In the past, I have regularly sent feedback to Python to 
    fix their header files, but this is getting old, and we have an easier 
    solution now.)
  2. Re: apply pragma system_header to python headers

    Andrew Dunstan <andrew@dunslane.net> — 2023-11-06T13:34:41Z

    On 2023-11-06 Mo 07:02, Peter Eisentraut wrote:
    > Analogous to 388e80132c (which was for Perl) but for Python, I propose 
    > adding #pragma GCC system_header to plpython.h.  Without it, you get 
    > tons of warnings about -Wdeclaration-after-statement, starting with 
    > Python 3.12.  (In the past, I have regularly sent feedback to Python 
    > to fix their header files, but this is getting old, and we have an 
    > easier solution now.)
    
    
    WFM
    
    
    cheers
    
    
    andrew
    
    --
    Andrew Dunstan
    EDB: https://www.enterprisedb.com
    
    
    
    
    
  3. Re: apply pragma system_header to python headers

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-11-06T14:57:00Z

    Peter Eisentraut <peter@eisentraut.org> writes:
    > Analogous to 388e80132c (which was for Perl) but for Python, I propose 
    > adding #pragma GCC system_header to plpython.h.  Without it, you get 
    > tons of warnings about -Wdeclaration-after-statement, starting with 
    > Python 3.12.  (In the past, I have regularly sent feedback to Python to 
    > fix their header files, but this is getting old, and we have an easier 
    > solution now.)
    
    +1 for the concept --- I was just noticing yesterday that my buildfarm
    warning scraping script is turning up some of these.  However, we ought
    to try to minimize the amount of our own code that is subject to the
    pragma.  So I think a prerequisite ought to be to get this out of
    plpython.h:
    
    /*
     * Used throughout, so it's easier to just include it everywhere.
     */
    #include "plpy_util.h"
    
    Alternatively, is there a way to reverse the effect of the
    pragma after we've included what we need?
    
    (I'm not too happy about the state of plperl.h on this point, either.)
    
    			regards, tom lane
    
    
    
    
  4. Re: apply pragma system_header to python headers

    Andrew Dunstan <andrew@dunslane.net> — 2023-11-06T15:30:28Z

    On 2023-11-06 Mo 09:57, Tom Lane wrote:
    > Peter Eisentraut <peter@eisentraut.org> writes:
    >> Analogous to 388e80132c (which was for Perl) but for Python, I propose
    >> adding #pragma GCC system_header to plpython.h.  Without it, you get
    >> tons of warnings about -Wdeclaration-after-statement, starting with
    >> Python 3.12.  (In the past, I have regularly sent feedback to Python to
    >> fix their header files, but this is getting old, and we have an easier
    >> solution now.)
    > +1 for the concept --- I was just noticing yesterday that my buildfarm
    > warning scraping script is turning up some of these.  However, we ought
    > to try to minimize the amount of our own code that is subject to the
    > pragma.  So I think a prerequisite ought to be to get this out of
    > plpython.h:
    >
    > /*
    >   * Used throughout, so it's easier to just include it everywhere.
    >   */
    > #include "plpy_util.h"
    >
    > Alternatively, is there a way to reverse the effect of the
    > pragma after we've included what we need?
    
    
    There's "GCC diagnostic push" and "GCC diagnostic pop" but I don't know 
    if they apply to "GCC system_header". Instead of using "GCC 
    system_header" we could just ignore the warnings we're seeing. e.g. "GCC 
    diagnostic ignored \"-Wdeclaration-after-statement\""
    
    
    cheers
    
    
    andrew
    
    --
    Andrew Dunstan
    EDB: https://www.enterprisedb.com
    
    
    
    
    
  5. Re: apply pragma system_header to python headers

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-11-06T16:06:29Z

    Andrew Dunstan <andrew@dunslane.net> writes:
    > On 2023-11-06 Mo 09:57, Tom Lane wrote:
    >> +1 for the concept --- I was just noticing yesterday that my buildfarm
    >> warning scraping script is turning up some of these.  However, we ought
    >> to try to minimize the amount of our own code that is subject to the
    >> pragma.  So I think a prerequisite ought to be to get this out of
    >> plpython.h:
    >> 
    >> /*
    >> * Used throughout, so it's easier to just include it everywhere.
    >> */
    >> #include "plpy_util.h"
    >> 
    >> Alternatively, is there a way to reverse the effect of the
    >> pragma after we've included what we need?
    
    > There's "GCC diagnostic push" and "GCC diagnostic pop" but I don't know 
    > if they apply to "GCC system_header". Instead of using "GCC 
    > system_header" we could just ignore the warnings we're seeing. e.g. "GCC 
    > diagnostic ignored \"-Wdeclaration-after-statement\""
    
    Probably a better way is to invent a separate header "plpython_system.h"
    that just includes the Python headers, to scope the pragma precisely.
    (I guess it could have the fixup #defines we're wrapping those headers
    in, too.)
    
    The same idea would work in plperl.
    
    			regards, tom lane
    
    
    
    
  6. Re: apply pragma system_header to python headers

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-12-25T17:36:50Z

    I wrote:
    > Probably a better way is to invent a separate header "plpython_system.h"
    > that just includes the Python headers, to scope the pragma precisely.
    > (I guess it could have the fixup #defines we're wrapping those headers
    > in, too.)
    
    > The same idea would work in plperl.
    
    After updating one of my test machines to Fedora 39, I'm seeing these
    Python warnings too.  So here's a fleshed-out patch proposal for doing
    it like that.
    
    			regards, tom lane