[PATCH] D153914: [clang-cl] Enable concatenation of predefined identifiers

[Richard Dzenis via Phabricator via cfe-commits]

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 <dzenis at 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