https://github.com/diseraluca closed
https://github.com/llvm/llvm-project/pull/67566
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
diseraluca wrote:
Closing this one, as we intend to maintain our own local version.
https://github.com/llvm/llvm-project/pull/67566
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
diseraluca wrote:
> > @vgvassilev If that is an acceptable interface for the LLVM interface then,
> > yes, it would be perfect from our side, and I'm more than happy to update
> > the PR in the next few days.
> > Just to be sure that I understood your proposal.
> > `getFullyQualified*` calls
vgvassilev wrote:
> @vgvassilev If that is an acceptable interface for the LLVM interface then,
> yes, it would be perfect from our side, and I'm more than happy to update the
> PR in the next few days.
>
> Just to be sure that I understood your proposal.
>
> `getFullyQualified*` calls will
diseraluca wrote:
@vgvassilev If that is an acceptable interface for the LLVM interface then,
yes, it would be perfect from our side, and I'm more than happy to update the
PR in the next few days.
Just to be sure that I understood your proposal.
`getFullyQualified*` calls will accept a new
vgvassilev wrote:
@diseraluca, since this code touches a case where we do some best effort
recovery, would it be possible to change that interface to take a
lambda/callback function and specialize it in your end to cover the docs case?
https://github.com/llvm/llvm-project/pull/67566
diseraluca wrote:
> I still do not see why the proposed solution would not work. If it solves
> the minimal case that you provided in the description of this PR, I am afraid
> that there is some bit from the Qt setup that we do not understand.
I cannot for certain say if there is an issue or
vgvassilev wrote:
> Wouldn't isExplicitSpecializationOrInstantiation be a stronger guarantee than
> isExplicitSpecialization, such that it would exclude a superset of what is
> excluded by isExplicitSpecialization? If I did not misunderstand their source
> code.
I wanted to filter out
diseraluca wrote:
> > > > I gave it a quick try, and we would still end up with the same result
> > > > in our codebase. But, generally, this would not probably be feasible
> > > > for us as a solution.
> > >
> > >
> > > do you have an idea why? Can you show the diff of the changes you made?
vgvassilev wrote:
> > > I gave it a quick try, and we would still end up with the same result in
> > > our codebase. But, generally, this would not probably be feasible for us
> > > as a solution.
> >
> >
> > do you have an idea why? Can you show the diff of the changes you made? Is
> > the
diseraluca wrote:
> > I gave it a quick try, and we would still end up with the same result in
> > our codebase. But, generally, this would not probably be feasible for us as
> > a solution.
>
> do you have an idea why? Can you show the diff of the changes you made? Is
> the void
vgvassilev wrote:
> I gave it a quick try, and we would still end up with the same result in our
> codebase. But, generally, this would not probably be feasible for us as a
> solution.
do you have an idea why? Can you show the diff of the changes you made? Is the
void specialization not
diseraluca wrote:
> @diseraluca, thanks for the thorough description. The point of these routines
> is to produce code that compiles. I am not sure if we change `Foo::Bar`
> with `Foo::Bar` it will compile.
>
> > Due to the way the current codebase is set up, the chosen specialization is
> >
vgvassilev wrote:
@diseraluca, thanks for the thorough description. The point of these routines
is to produce code that compiles. I am not sure if we change `Foo::Bar`
with `Foo::Bar` it will compile.
> Due to the way the current codebase is set up, the chosen specialization is
> `QFuture`
mizvekov wrote:
It's recommended to avoid introducing pure clang-format changes mixed with
other non-style changes.
The recommended way to avoid that is to run clang-format on the modified files
on a separate commit, and then just merge that, no review required.
diseraluca wrote:
Run clang-format on the patch.
I made a bit of a mess as I haven't used the PR model in a very long time.
Hopefully this is correct.
https://github.com/llvm/llvm-project/pull/67566
___
cfe-commits mailing list
https://github.com/diseraluca edited
https://github.com/llvm/llvm-project/pull/67566
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/diseraluca edited
https://github.com/llvm/llvm-project/pull/67566
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
18 matches
Mail list logo
