compnerd wrote:
> But this before we do that, we need to have some kind of mechanism in place
> so we can actually enumerate the AP However, we already expose everything in
> the API, and just adding the annotations doesn't change that (although I
> think it may slightly reduce the number of s
tstellar wrote:
> Well, we're currently approaching this from the angle of "expose everything
> and then the user can do whatever they want", but perhaps the discussion we
> should be having is "what use cases do we explicitly want to support?" and
> then we write plugins to demonstrate that w
rnk wrote:
I think it makes sense to focus on Saleem's use case, which, perhaps to
translate it into Posix-ecosystem terms, is to create a single Clang DSO
(similar to llvm-dylib or whatever we call it) that all the affiliated monorepo
Clang tools use (clang-tidy, clang-rename, clang-format, c
compnerd wrote:
> Well, we're currently approaching this from the angle of "expose everything
> and then the user can do whatever they want", but perhaps the discussion we
> should be having is "what use cases do we explicitly want to support?" and
> then we write plugins to demonstrate that w
AaronBallman wrote:
> > > The default behaviour of `ids` is to assume that anything declared in the
> > > header is public and it will ensure that anything added in the headers is
> > > annotated properly to say it is exposed, making something private would
> > > be an explicit decision that t
compnerd wrote:
> > I can absolutely see the value in the opposite - minimise the ABI surface.
> > For many projects, there is a split of internal and external headers. The
> > idea is that this tool is only run on the external headers, so those are
> > meant to be ABI.
>
> There were multipl
fsfod wrote:
> I can absolutely see the value in the opposite - minimise the ABI surface.
> For many projects, there is a split of internal and external headers. The
> idea is that this tool is only run on the external headers, so those are
> meant to be ABI.
There were multiple internals hea
compnerd wrote:
> > The default behaviour of `ids` is to assume that anything declared in the
> > header is public and it will ensure that anything added in the headers is
> > annotated properly to say it is exposed, making something private would be
> > an explicit decision that the developer
AaronBallman wrote:
> The default behaviour of `ids` is to assume that anything declared in the
> header is public and it will ensure that anything added in the headers is
> annotated properly to say it is exposed, making something private would be an
> explicit decision that the developer nee
vgvassilev wrote:
A gentle ping on reviewing.
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
compnerd wrote:
> pre-commit actions are expensive, but I think we could afford to do something
> here. It is not hard to set up a DLL build of an ELF DSO build that uses
> these annotations, and it's cheaper than a fully static build.
Having a fast incremental build for DLL-enabled LLVM/clang
tstellar wrote:
Is there any reason why the tool should be in the monorepo and not some other
repository?
Also, as for keeping the annotations up-to-date. My recommendation is to add a
github action job that runs the ids tool and then submits a pull request for
any necessary changes. We co
fsfod wrote:
> I'd like some answer about how we plan to ensure the macros remain correct.
> Short-term, "someone periodically runs the tool manually" might be good
> enough if we don't expect much churn, I guess.
Missing macros on some classes or functions shouldn't break any existing
config
efriedma-quic wrote:
I'd like some answer about how we plan to ensure the macros remain correct.
Short-term, "someone periodically runs the tool manually" might be good enough
if we don't expect much churn, I guess.
Also, can the tool itself be added to llvm-project?
(The actual changes seem
vgvassilev wrote:
@efriedma-quic, @rnk, @compnerd, @AaronBallman can we make another round of
review here?
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
https://github.com/fsfod ready_for_review
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vgvassilev wrote:
> Processing just header is also much faster than a full build and I think it
> would only have to run on changed headers and source files for a PR.
Any ideas how to implement that check? If we have a draft implementation we can
check with the the ci folks how to deploy it...
fsfod wrote:
Processing just header is also much faster than a full build and I think it
would only have to run on changed headers and source files for a PR.
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@li
rnk wrote:
> Is there a plan for maintaining these annotations long-term? Like, should
> there be a pre-commit action to verify that all the annotations are
> up-to-date?
pre-commit actions are expensive, but I think we could afford to do something
here. It is not hard to set up a DLL build o
efriedma-quic wrote:
Is there a plan for maintaining these annotations long-term? Like, should
there be a pre-commit action to verify that all the annotations are up-to-date?
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing li
compnerd wrote:
> Looking at Format.h (the only file I'm interested in), there feels to me to
> be things in the ABI that I wouldn't expect to be called externally, I don't
> know enough about what's involved in creating a DLL ABI but I wouldn't want
> some of the clang-format functions to be
fsfod wrote:
If your stuck with having to include a class or function it in a public header
there will be a macro you can add to it so the Clang tool skips adding
visibility attributes added to it. At the file or folder level they can be
excluded by adding them to the export config file used b
mydeveloperday wrote:
Looking at Format.h (the only file I'm interested in), there feels to me to be
things in the ABI that I wouldn't expect to be called externally, I don't know
enough about what's involved in creating a DLL ABI but I wouldn't want some of
the clang-format functions to be i
https://github.com/fsfod converted_to_draft
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/fsfod edited https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/fsfod edited https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/fsfod edited https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
@fsfod Can you update the first comment to describe the overall purpose of this
change? That seems pretty central to understanding whether we want this, and if
so, whether this looks like the right set of annotations.
https://github.com/llvm/llvm-project/pull/109702
___
https://github.com/fsfod edited https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Thomas Fransham (fsfod)
Changes
The visibility macros generated here are created by a
[ids](https://github.com/fsfod/ids) clang tooling based tool that @compnerd wrote and I've extended.
To reduce the numbers of exports and to avoid explic
llvmbot wrote:
@llvm/pr-subscribers-backend-arm
Author: Thomas Fransham (fsfod)
Changes
The visibility macros generated here are created by a
[ids](https://github.com/fsfod/ids) clang tooling based tool that @compnerd wrote and I've extended.
To reduce the numbers of exports and to avoid
llvmbot wrote:
@llvm/pr-subscribers-backend-risc-v
Author: Thomas Fransham (fsfod)
Changes
The visibility macros generated here are created by a
[ids](https://github.com/fsfod/ids) clang tooling based tool that @compnerd wrote and I've extended.
To reduce the numbers of exports and to avo
llvmbot wrote:
@llvm/pr-subscribers-hlsl
Author: Thomas Fransham (fsfod)
Changes
The visibility macros generated here are created by a
[ids](https://github.com/fsfod/ids) clang tooling based tool that @compnerd wrote and I've extended.
To reduce the numbers of exports and to avoid explici
llvmbot wrote:
@llvm/pr-subscribers-clang-analysis
@llvm/pr-subscribers-backend-aarch64
Author: Thomas Fransham (fsfod)
Changes
The visibility macros generated here are created by a
[ids](https://github.com/fsfod/ids) clang tooling based tool that @compnerd wrote and I've extended.
To red
34 matches
Mail list logo
