hahnjo wrote:
> Here's a new reproducer, this time verifying that a semi-fresh
> tip-of-the-tree doesn't trigger the same error:
> https://pastebin.com/7tYfjazz. Apologies for the delay.
Thanks. I gave it a try, but I don't see any `use of overloaded operator '=' is
ambiguous` error. In fact,
hahnjo wrote:
> When I have time, I will need to see that I turn the reduced example into
> actual valid code to understand what is going on...
I spent some time turning it into valid code, but then noticed that the `error:
use of overloaded operator '=' is ambiguous` is gone. Going back, the
@@ -367,12 +367,6 @@ bool RedeclarableTemplateDecl::loadLazySpecializationsImpl(
if (!ExternalSource)
return false;
- // If TPL is not null, it implies that we're loading specializations for
- // partial templates. We need to load all specializations in such cases.
-
@@ -21,17 +21,6 @@ using namespace clang;
namespace {
class TemplateArgumentHasher {
- // If we bail out during the process of calculating hash values for
- // template arguments for any reason. We're allowed to do it since
- // TemplateArgumentHasher are only required to g
@@ -367,12 +367,6 @@ bool RedeclarableTemplateDecl::loadLazySpecializationsImpl(
if (!ExternalSource)
return false;
- // If TPL is not null, it implies that we're loading specializations for
- // partial templates. We need to load all specializations in such cases.
-
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/137804
Recently commit dc17429ae6 removed some code related to template arguments in
`NestedNameSpecifier::print` that would not pass on the
`TemplateParameterList`. This would cause `printIntegral` to add type suffixe
hahnjo wrote:
> > As far as I can tell, -fincremental-extensions should set the language
> > option IncrementalExtensions which in turn is the default for
> > Preprocessor::IncrementalProcessing.
>
> It is true that it is the default, but it's possible for clients to have one
> without the ot
https://github.com/hahnjo closed
https://github.com/llvm/llvm-project/pull/137804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
> Maybe you can test it with this and land it with different patches. So that
> we can revert one of them if either of them are problematic but other parts
> are fine.
I'm ok with pushing the commits one-by-one after the PR is reviewed, just let
me know.
> > Complete only neede
@@ -367,12 +367,6 @@ bool RedeclarableTemplateDecl::loadLazySpecializationsImpl(
if (!ExternalSource)
return false;
- // If TPL is not null, it implies that we're loading specializations for
- // partial templates. We need to load all specializations in such cases.
-
hahnjo wrote:
Thanks, the reproducer is indeed useful. The first "bad" commit is the second
`Complete only needed partial specializations`.
I was manually able to further reduce the example (throwing out empty files &
modules, inline through typedefs, etc)
Smaller reproducer
```
//--- 2OT.h
hahnjo wrote:
I'm not so sure it's about conversion function templates in particular: if it's
really commit 658d55ba1117a029f37f51a3072585a1fd9fc59f causing the problem
(@emaxx-google if you happen to have some time, it would be great to confirm
reverting that change also avoids the issues in
hahnjo wrote:
> @hahnjo, if we have a working reproducer could we see if @zygoloid's comment
> helps us:
>
> > If this issue is indeed specific to conversion function templates, perhaps
> > a path forward would be to disable some part of the lazy loading for only
> > those templates to unbloc
https://github.com/hahnjo converted_to_draft
https://github.com/llvm/llvm-project/pull/133057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
I don't think we should merge a partial state of this PR for two reasons: 1.
The three patches alone don't actually bring much benefit. When I measured in
ROOT, we definitely needed the (currently) problematic one for lazy template
loading to become really effective. 2. As commen
301 - 315 of 315 matches
Mail list logo
