Date: Mon, 20 Sep 2021 19:01:52 +0300
On Mon, 20 Sept 2021 at 18:57, Aaron Ballman
<compatibility.sg.chair_at_[hidden]> wrote:
> > > There are compilers for which the implementation strategy for all
> > > attributes is to note the [[ that opens an attribute specifier, eat
> > > all balanced tokens up to the closing ]], and diagnose the entire bit
> > > as "attribute ignored" (as a warning). You cannot do that with
> It is a conforming strategy because of the laxity in what diagnostics
> are required for conformance. "attribute ignored" is a low-quality
> diagnostic for [[12]] but is still a conforming implementation. The
> issue with contracts is that there are additional semantics that can't
> be ignored.
Oops, sorry, I managed to convince my brain to not read the "and
diagnose" part of your explanation. :D
Do we have any concrete suggestions for making it easier for a C
compiler to barf harder on a C++ contract annotation,
perhaps in a way that doesn't require the C compiler to change its
attribute-processing approach?
<compatibility.sg.chair_at_[hidden]> wrote:
> > > There are compilers for which the implementation strategy for all
> > > attributes is to note the [[ that opens an attribute specifier, eat
> > > all balanced tokens up to the closing ]], and diagnose the entire bit
> > > as "attribute ignored" (as a warning). You cannot do that with
> It is a conforming strategy because of the laxity in what diagnostics
> are required for conformance. "attribute ignored" is a low-quality
> diagnostic for [[12]] but is still a conforming implementation. The
> issue with contracts is that there are additional semantics that can't
> be ignored.
Oops, sorry, I managed to convince my brain to not read the "and
diagnose" part of your explanation. :D
Do we have any concrete suggestions for making it easier for a C
compiler to barf harder on a C++ contract annotation,
perhaps in a way that doesn't require the C compiler to change its
attribute-processing approach?
Received on 2021-09-20 11:02:36