RIscRIpt added a comment.
In D153914#4570148 <https://reviews.llvm.org/D153914#4570148>, @cor3ntin wrote:
> We will commit on your behalf, what name/email do you want us to use?
> Thanks!
Thanks for asking; keep the name/email as-is in the commit you see: `Author:
Richard Dzenis <dze...@richard.lv>`
================
Comment at: clang/lib/Sema/Sema.cpp:1494-1505
+Decl *Sema::getCurLocalScopeDecl() {
+ if (const BlockScopeInfo *BSI = getCurBlock())
+ return BSI->TheDecl;
+ else if (const LambdaScopeInfo *LSI = getCurLambda())
+ return LSI->CallOperator;
+ else if (const CapturedRegionScopeInfo *CSI = getCurCapturedRegion())
+ return CSI->TheCapturedDecl;
----------------
aaron.ballman wrote:
> Made the function `const` because it's not writing to any fields, removed
> `else` because of preceding `return`.
I would love to, and I tried. But unfortunately it's not possible without
introducing more changes: all the member functions (except
`getCurFunctionOrMethodDecl()`) are non-const.
Removed `else`.
================
Comment at: clang/lib/Sema/SemaExpr.cpp:1998-2000
+ if (isa<TranslationUnitDecl>(currentDecl)) {
+ Diag(Tok.getLocation(), diag::ext_predef_outside_function);
+ }
----------------
aaron.ballman wrote:
> This will miss the diagnostic if the current declaration is a namespace
> instead of at file scope, right?
Right. But `getCurLocalScopeDecl()` returns function scope at most. See Note in
a code comment above.
================
Comment at: clang/lib/Sema/SemaExpr.cpp:2001-2004
+ OS << '"'
+ << Lexer::Stringify(PredefinedExpr::ComputeName(
+ getPredefinedExprKind(Tok.getKind()), currentDecl))
+ << '"';
----------------
tahonermann wrote:
> RIscRIpt wrote:
> > tahonermann wrote:
> > > A diagnostic is issued if the call to `getCurScopeDecl()` returned a
> > > translation unit declaration (at least in Microsoft mode). Does it make
> > > sense to pass a pointer to a `TranslationUnitDecl` here?
> > Shortly, yes, kind of. `ComputeName` can handle `TranslationUnitDecl` in
> > which case it returns an empty string. This way we implicitly (without
> > additional code) create empty string-literal Tokens which can be handled in
> > `StringLiteralParser`. And we cannot pass non-string-literal tokens into
> > `StringLiteralParser`.
> Ah, ok. And I see it even differentiates what name is produced for
> `__PRETTY_FUNCTION__`. That leaves me wondering what the right behavior
> should be at class and namespace scope, but maybe I'm better off not asking
> questions I don't want to know the answer to.
> A diagnostic is issued if the call to `getCurScopeDecl()` returned a
> translation unit declaration (at least in Microsoft mode). Does it make sense
> to pass a pointer to a `TranslationUnitDecl` here?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D153914/new/
https://reviews.llvm.org/D153914
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
