rjmccall wrote:
> > The upshot is that we don't (and shouldn't) ever late-parse at file
> > context, which by design means we can't see stack-manipulating pragmas
> > because they're all restricted to file context. In late parsing, we only
> > ever observe and change the innermost state of the pragma stack, and so all
> > we need to do is temporarily restore that innermost state to what it was
> > when the tokens were originally captured, then restore it to its "live"
> > value after the late parsing is complete. The rest of the stack is
> > untouchable.
>
> "shouldn't ever late parse at file context" is something I agree with when I
> think about most language constructs, but as a counter-example, folks have
> been agitating more and more for the ability for an attribute argument to
> reference a subsequent declaration. e.g.,
>
> ```
> void func(int *ptr [[attr(len)]], size_t len);
>
> struct S {
> int *Ptr [[attr(len)]];
> int Len;
> };
> ```
>
> and the likes. I can imagine someone wanting to extend that to:
>
> ```
> int *GlobalArray [[attr(GlobalLen)]];
> int GlobalLen;
> ```
>
> because reordering the globals may change other semantic behavior (like
> initialization order for dynamic init). Should we perhaps add documentation
> to the internals manual so we capture the issues with file-scope late parsing?
Yes, I think that'd be good. To me, the right way of thinking about this kind
of code is that it's not truly at file context — it's not really standalone, we
just don't really have the `Decl` that it's part of yet. For example, there's
a lot of things you really shouldn't be able to write in a statement-expression
in a global initializer, the bound of an array type, and so on, but our
checking doesn't always prohibit them because e.g. there isn't a meaningful
`DeclContext` we can put in `CurContext` that will reflect that this isn't
really a local context. (The way we solved this in Swift's AST is that a
`DeclContext` doesn't have to be a `Decl`, and we lazily create an
`Initializer` DC when processing other kinds of top-level expressions.) This
is a longstanding issue.
https://github.com/llvm/llvm-project/pull/70646
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
