On Tue, Sep 16, 2025 at 6:25 PM Yeoul Na <[email protected]> wrote:
> On Sep 16, 2025, at 4:32 PM, Bill Wendling <[email protected]> wrote: > On Tue, Sep 16, 2025 at 11:39 AM Yeoul Na <[email protected]> wrote: > >> Hi folks, >> >> Hi Yeoul, > > I wanted to share some updates from our WG14 meeting in Brno, where we >> presented our proposal on dependent attributes. >> >> # Our Proposal >> >> We presented N3656 (www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf), >> which introduces "Dependent Attributes" as a new category of attributes >> that need to reference other program entities (with __counted_by(len) as >> the primary example). The proposal defines two key behaviors for name >> lookup: >> >> Forward lookup (delayed parsing) to reference not-yet-declared structure >> members or parameters >> Direct member access using identifier names without prefixes >> >> # Voting Results >> >> After discussions, we put forward three questions to the committee: >> >> 1. Name lookup mechanism*:* Is WG14 in favor of the name lookup >> mechanism for dependent attributes proposed in N3656? >> >> Result: Weak in favor. More members voted in favor than against. >> Committee feedback indicated a desire for well-defined restriction rules >> for expressions within __counted_by and similar attributes to minimize >> potential issues with delayed parsing. >> >> 2. Diagnostics for name conflicts: Is WG14 against diagnosing name >> conflicts for array parameter size? >> >> int size; // name conflict - diagnose as potential mistake >> void foo(int arr[size], int size); >> >> Result: Strong direction for adding diagnostics. MISRA C already forbids >> such shadowing as error-prone. These diagnostics will help us understand >> how frequently this pattern occurs and its impact. >> >> 3. Forward declaration approach: Does WG14 want to see something along >> the lines of N3433 (www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf)? >> >> Result: No consensus. More members voted against this approach, despite >> previous "along the lines" support. Several members changed their position >> due to the delayed parsing alternative and Clang's opposition to the >> forward declaration approach. >> >> # Next Steps >> >> Based on this feedback, we're proceeding with: >> >> ## Specification work: >> >> - Formalize restrictions for expressions in dependent attributes in the >> revised proposal >> - Submit a standard proposal specifically for bounds attributes (N3656 >> focused on name lookup rules rather than specific attributes) >> >> ## Implementation in Clang: >> >> - Add diagnostics for name conflicts in array parameter size, potentially >> proposing it as ill-formed if results support it. >> - Continue open-sourcing -fbounds-safety for features not dependent on >> complex expressions in counted_by. This will still allow adopting the >> annotation in most of the use cases. >> - Implement the proposed name lookup rule under an experimental flag with >> formalized restrictions to verify the approach in Clang. >> >> ## Seeking Community Input: >> >> I'd like to hear what the GCC/Clang community thinks about the idea of >> specifying formal restrictions for expressions within the attributes to >> support delayed parsing. Or should we still seek alternatives to avoid >> delayed parsing? Your feedback on this approach would be valuable as we >> move forward with the implementation. >> >> Avoiding delayed parsing would be ideal, but as your paper pointed out it > won't be possible in all situations. I thought your paper made a very solid > case for the current syntax, which would require some form of late / > delayed parsing. Is it fair to assume that once you do the "specification > work" then the committee is inclined to accept your proposal? > > > This is a bit complicated. N3656 was not written to be added to the > standard directly. Instead, we wrote it to get direction and advice from > WG14, and to work with them on making a specification that compilers like > GCC and Clang can implement. We got weak support in favor, which I took as > encouragement to continue working in this direction. Some committee members > even told us that since these are attributes, we can do what we want in the > compilers. > > Based on this feedback, our near-term goal is to work on the specification > and get some good committee members to review it, to make sure it makes > sense and can be implemented in compilers like GCC and Clang. > > That sounds great! As an aside, I wrote a proof-of-concept patch for GCC that performs delayed > parsing. There was pushback because it didn't ensure the expression was > context-free, but that could be checked for and rejected accordingly. I > point this out to show that it's not necessarily an impediment to adoption > as the changes were relatively small. > > > Oh interesting! So the GCC community wanted the expression to be > context-free? Like only allowing a subset of expressions that are > guaranteed to be context-free? We can work on specifying such a subset for > the attributes. > > That's what I got from the discussions. I of course can't speak for all of GCC, but if we did ensure the expressions were context-free, it would remove the issue of losing context. That said the patch I sent out wasn't particularly popular with the GCC community, and the conversation was put on hold until after the Brno meeting, so I suspect there is still much to discuss. -bw
