[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 212509.
serge-sans-paille added a comment.
Herald added subscribers: dexonsmith, steven_wu.

- Test extension point registration when extension is built-in
- Correctly handle -DLLVM_LINK_LLVM_DYLIB=0
- Fix a few details


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61446/new/

https://reviews.llvm.org/D61446

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CMakeLists.txt
  clang/tools/driver/CMakeLists.txt
  clang/tools/driver/cc1_main.cpp
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/docs/WritingAnLLVMPass.rst
  llvm/examples/Bye/Bye.cpp
  llvm/examples/Bye/CMakeLists.txt
  llvm/examples/CMakeLists.txt
  llvm/include/llvm/Config/llvm-config.h.cmake
  llvm/test/Feature/load_extension.ll
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/opt-O0-pipeline.ll
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/test/lit.cfg.py
  llvm/test/lit.site.cfg.py.in
  llvm/tools/CMakeLists.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/opt/CMakeLists.txt
  llvm/tools/opt/NewPMDriver.cpp
  llvm/tools/opt/opt.cpp
  llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
  polly/include/polly/RegisterPasses.h
  polly/lib/CMakeLists.txt
  polly/lib/Polly.cpp
  polly/lib/Support/RegisterPasses.cpp
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in
  polly/test/update_check.py

Index: polly/test/update_check.py
===
--- polly/test/update_check.py
+++ polly/test/update_check.py
@@ -15,7 +15,7 @@
 polly_lib_dir = '''@POLLY_LIB_DIR@'''
 shlibext = '''@LLVM_SHLIBEXT@'''
 llvm_tools_dir = '''@LLVM_TOOLS_DIR@'''
-link_polly_into_tools = not '''@LINK_POLLY_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','link_polly_into_tools-notfound'}
+llvm_polly_link_into_tools = not '''@LLVM_POLLY_LINK_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','llvm_polly_link_into_tools-notfound'}
 
 runre = re.compile(r'\s*\;\s*RUN\s*\:(?P.*)')
 filecheckre = re.compile(r'\s*(?P.*)\|\s*(?PFileCheck\s[^|]*)')
@@ -298,7 +298,7 @@
 toolarg = toolarg.replace('%s', filename)
 toolarg = toolarg.replace('%S', os.path.dirname(filename))
 if toolarg == '%loadPolly':
-if not link_polly_into_tools:
+if not llvm_polly_link_into_tools:
 newtool += ['-load',os.path.join(polly_lib_dir,'LLVMPolly' + shlibext)]
 newtool.append('-polly-process-unprofitable')
 newtool.append('-polly-remarks-minimal')
Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -8,7 +8,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
 config.extra_paths = "@POLLY_TEST_EXTRA_PATHS@".split(";")
 
@@ -36,14 +36,14 @@
 # directories.
 config.excludes = ['Inputs']
 
-if config.link_polly_into_tools == '' or \
-   config.link_polly_into_tools.lower() == '0' or \
-   config.link_polly_into_tools.lower() == 'n' or \
-   config.link_polly_into_tools.lower() == 'no' or \
-   config.link_polly_into_tools.lower() == 'off' or \
-   config.link_polly_into_tools.lower() == 'false' or \
-   config.link_polly_into_tools.lower() == 'notfound' or \
-   config.link_polly_into_tools.lower() == 'link_polly_into_tools-notfound':
+if config.llvm_polly_link_into_tools == '' or \
+   config.llvm_polly_link_into_tools.lower() == '0' or \
+   config.llvm_polly_link_into_tools.lower() == 'n' or \
+   config.llvm_polly_link_into_tools.lower() == 'no' or \
+   config.llvm_polly_link_into_tools.lower() == 'off' or \
+   config.llvm_polly_link_into_tools.lower() == 'false' or \
+   config.llvm_polly_link_into_tools.lower() == 'notfound' or \
+   config.llvm_polly_link_into_tools.lower() == 'llvm_polly_link_into_tools-notfound':
 config.substitutions.append(('%loadPolly', '-load '
  + config.polly_lib_dir + '/LLVMPolly@LLVM_SHLIBEXT@'
  + ' -load-pass-plugin '
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -13,7 +13,7 @@
 config.shlibdir = "@SHLIBDIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_

[PATCH] D62525: [Analyzer] Add new visitor to the iterator checkers

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

I don't see obvious red flags here, @NoQ?

In D62525#1523026 , 
@baloghadamsoftware wrote:

> In D62525#1519868 , @NoQ wrote:
>
> > In D62525#1519475 , 
> > @baloghadamsoftware wrote:
> >
> > > Before someone asks: `NoteTag`s are not applicable here since 
> > > invalidation and reaching one end of the range happens in many different 
> > > places. This is also true for container emptiness.
> >
> >
> > Mm, what's wrong with many different places? If you're worried about code 
> > duplication, just put tag construction into a function (?)
>
>
> It is not about code duplication. Of course, that can be handled by a 
> function.
>
> The problem is that the transition is added in the top level function but 
> iterator position adjustments happen in the lower level ones. Data flow is 
> one-way, top-down. For example, an insertion happens into a vector that 
> invalidates all the iterators at and after the position where it is inserted. 
> In this case `handleInsert()` calls a function that iterates all the active 
> iterator positions and calls other one that invalidates the ones affected by 
> the insertion. To propagate back the list of iterators invalidated would be 
> too complex. Increments and decrements are even worse. Thus here the correct 
> way seems to find the relevant transitions in a visitor instead of trying to 
> figure out what note tags to add at each transition.


Mhm, I personally find this reasoning sufficient.




Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:281-282
+
+  // `FoundChange` becomes true when we find the statement the results in the
+  // current state of the iterator.
+  // `FoundEmptyness` becomes true when we find the block edge assuming

baloghadamsoftware wrote:
> NoQ wrote:
> > I don't think we should stop here. I think it's worth it to highlight *all* 
> > increments and decrements of the interesting iterator, so that it was clear 
> > how come that it has the given value.
> > 
> > Additionally, because iterators are copied around, it makes sense to 
> > "recursively" apply the visitor to the original object when the iterator is 
> > obtained as a copy (similarly to how `trackExpressionValue` works).
> This can be done but an iterator can reach the past-the-end or the first 
> position by changing the container's size as well, not only by incrementing 
> or decrementing the iterator itself.
Maybe in a followup patch, but I'd love to see a `trackIterator` function!



Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:1277-1292
+State = setContainerData(State, ContReg, CData->newEnd(OldEndSym));
   } else {
 State = setContainerData(State, ContReg,
- ContainerData::fromEnd(NewEndSym));
+ ContainerData::fromEnd(OldEndSym));
   }
+  // Then generate and assign a new "end" symbol for the old container.
+  auto NewEndSym =

baloghadamsoftware wrote:
> Szelethus wrote:
> > I'm confused, are these changes related to this patch? It doesn't seem to 
> > be.
> Yes, they are. Since we want to track the iterator positions upwards along 
> the bugpath as far a possible I had to reverse one of my decisions. When I 
> first decided it was really like a coin thrown up, but now it turned out I 
> took the wrong choice considering the visitor. The change is that upon move 
> assignment of a container the iterators are transferred to the new container, 
> except the past-the-end iterator.  However we also have iterator positions 
> relative to the past-the-end iterator (thus using the same symbol) which must 
> be transferred. So I had to separate them from the past-the-end positions by 
> generating a new end symbol. I originally used this new symbol for the 
> positions to be transferred and kept the old symbol for the past-the-end 
> positions. However this makes tracking of the non past-the-end positions very 
> difficult so I reversed it and now I transfer the old symbol and use the new 
> for the past-the-end positions.
Sometimes I just need a reality check to realize how absurdly difficult the 
problem is that you're solving... Wow. I mentioned this elsewhere, but do we 
not need a debug checker to validate that we argue about all of these correctly?



Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:1495-1496
 
   // For deque-like containers invalidate all iterator positions. For
   // vector-like containers invalidate iterator positions after the insertion.
   const auto *Cont = Pos->getContainer();

>>! In D62525#1523026, @baloghadamsoftware wrote:
> For example, an insertion happens into a vector that invalidates all the 
> iterators at and after the position where it is in

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

@Meinersbur I've updated the test case to test extension point if the extension 
is linked in, this is not so intrusive, I'm happy with the solution.

Also fixed some linkage options when using llvm dynlib, validation looks nice 
on my side.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61446/new/

https://reviews.llvm.org/D61446



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65395: [clangd] Added a skeleton for a semantic highlighting feature to the vscode extension.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

The skeleton looks good, but apparently it does nothing (only enable the 
feature), do you have a small working prototype?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65395/new/

https://reviews.llvm.org/D65395



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65395: [clangd] Added a skeleton for a semantic highlighting feature to the vscode extension.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 212523.
jvikstrom added a comment.

Added check that clangd server actually supports semantic highlighting.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65395/new/

https://reviews.llvm.org/D65395

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/.gitignore
  clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -1,5 +1,6 @@
 import * as vscode from 'vscode';
 import * as vscodelc from 'vscode-languageclient';
+import { SemanticHighlighting } from './SemanticHighlighting';
 
 /**
  * Method to get workspace configuration option
@@ -12,9 +13,9 @@
 }
 
 namespace SwitchSourceHeaderRequest {
-export const type =
-new vscodelc.RequestType('textDocument/switchSourceHeader');
+export const type =
+new vscodelc.RequestType('textDocument/switchSourceHeader');
 }
 
 class FileStatus {
@@ -32,8 +33,8 @@
 const path = vscode.window.activeTextEditor.document.fileName;
 const status = this.statuses.get(path);
 if (!status) {
-  this.statusBarItem.hide();
-  return;
+this.statusBarItem.hide();
+return;
 }
 this.statusBarItem.text = `clangd: ` + status.state;
 this.statusBarItem.show();
@@ -73,25 +74,30 @@
 // However, VSCode does not have CUDA as a supported language yet, so we
 // cannot add a corresponding activationEvent for CUDA files and clangd will
 // *not* load itself automatically on '.cu' files.
-const cudaFilePattern: string = '**/*.{' +['cu'].join()+ '}';
+const cudaFilePattern: string = '**/*.{' + ['cu'].join() + '}';
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for c-family and cuda files.
 documentSelector: [
 { scheme: 'file', language: 'c' },
 { scheme: 'file', language: 'cpp' },
-{ scheme: 'file', language: 'objective-c'},
-{ scheme: 'file', language: 'objective-cpp'},
+{ scheme: 'file', language: 'objective-c' },
+{ scheme: 'file', language: 'objective-cpp' },
 { scheme: 'file', pattern: cudaFilePattern },
 ],
 synchronize: !syncFileEvents ? undefined : {
-// FIXME: send sync file events when clangd provides implemenatations.
+// FIXME: send sync file events when clangd provides implemenatations.
 },
 initializationOptions: { clangdFileStatus: true },
 // Do not switch to output window when clangd returns output
 revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never
 };
 
-const clangdClient = new vscodelc.LanguageClient('Clang Language Server',serverOptions, clientOptions);
+const clangdClient = new vscodelc.LanguageClient('Clang Language Server', serverOptions, clientOptions);
+const semanticHighlightingFeature = new SemanticHighlighting.Feature();
+clangdClient.registerFeature(semanticHighlightingFeature);
+// The notification handler must be registered after the client is ready or the client will crash.
+clangdClient.onReady().then(() => clangdClient.onNotification(SemanticHighlighting.NotificationType, semanticHighlightingFeature.handleNotification));
+
 console.log('Clang Language Server is now active!');
 context.subscriptions.push(clangdClient.start());
 context.subscriptions.push(vscode.commands.registerCommand(
@@ -131,5 +137,5 @@
 // An empty place holder for the activate command, otherwise we'll get an
 // "command is not registered" error.
 context.subscriptions.push(vscode.commands.registerCommand(
-'clangd-vscode.activate', async () => {}));
+'clangd-vscode.activate', async () => { }));
 }
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
===
--- /dev/null
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
@@ -0,0 +1,36 @@
+import * as vscodelc from 'vscode-languageclient';
+import { DocumentSelector } from 'vscode-languageclient';
+
+export namespace SemanticHighlighting {
+interface HighlightingInformation {
+textDocument: {
+uri: String,
+},
+lines: [{
+line: number,
+tokens: string,
+}],
+}
+
+export const NotificationType = new vscodelc.NotificationType<{}, void>('textDocument/semanticHighlighting');
+
+// The feature that should be registered in the vscode lsp for enabling experimental semantic highlighting.
+export 

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 212522.
jvikstrom marked 2 inline comments as done.
jvikstrom added a comment.

Stopped using expensive getLineNumber function.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -29,9 +29,7 @@
   return Tokens;
 }
 
-void checkHighlightings(llvm::StringRef Code) {
-  Annotations Test(Code);
-  auto AST = TestTU::withCode(Test.code()).build();
+std::vector getExpectedTokens(Annotations &Test) {
   static const std::map KindToString{
   {HighlightingKind::Variable, "Variable"},
   {HighlightingKind::Function, "Function"},
@@ -48,10 +46,47 @@
 Test.ranges(KindString.second), KindString.first);
 ExpectedTokens.insert(ExpectedTokens.end(), Toks.begin(), Toks.end());
   }
+  llvm::sort(ExpectedTokens);
+  return ExpectedTokens;
+}
+
+void checkHighlightings(llvm::StringRef Code) {
+  Annotations Test(Code);
+  auto AST = TestTU::withCode(Test.code()).build();
+  std::vector ActualTokens = getSemanticHighlightings(AST);
+  EXPECT_THAT(ActualTokens, getExpectedTokens(Test));
+}
+
+// Any annotations in OldCode and NewCode are converted into their corresponding
+// HighlightingToken. The tokens are diffed against each other. Any lines where
+// the tokens should diff must be marked with a ^ somewhere on that line in
+// NewCode. If there are diffs that aren't marked with ^ the test fails. The
+// test also fails if there are lines marked with ^ that don't differ.
+void checkDiffedHighlights(llvm::StringRef OldCode, llvm::StringRef NewCode) {
+  Annotations OldTest(OldCode);
+  Annotations NewTest(NewCode);
+  std::vector OldTokens = getExpectedTokens(OldTest);
+  std::vector NewTokens = getExpectedTokens(NewTest);
+
+  llvm::DenseMap> ExpectedLines;
+  for (const Position &Point : NewTest.points()) {
+ExpectedLines[Point.line]; // Default initialize to an empty line. Tokens
+   // are inserted on these lines later.
+  }
+  std::vector ExpectedLinePairHighlighting;
+  for (const HighlightingToken &Token : NewTokens) {
+auto It = ExpectedLines.find(Token.R.start.line);
+if (It != ExpectedLines.end())
+  It->second.push_back(Token);
+  }
+  for (auto &LineTokens : ExpectedLines)
+ExpectedLinePairHighlighting.push_back(
+{LineTokens.first, LineTokens.second});
 
-  auto ActualTokens = getSemanticHighlightings(AST);
-  EXPECT_THAT(ActualTokens, testing::UnorderedElementsAreArray(ExpectedTokens))
-   << "Inputs is:\n" << Code;
+  std::vector ActualDiffed =
+  diffHighlightings(NewTokens, OldTokens, NewCode.count('\n'));
+  EXPECT_THAT(ActualDiffed,
+  testing::UnorderedElementsAreArray(ExpectedLinePairHighlighting));
 }
 
 TEST(SemanticHighlighting, GetsCorrectTokens) {
@@ -226,8 +261,9 @@
 std::atomic Count = {0};
 
 void onDiagnosticsReady(PathRef, std::vector) override {}
-void onHighlightingsReady(
-PathRef File, std::vector Highlightings) override {
+void onHighlightingsReady(PathRef File,
+  std::vector Highlightings,
+  int NLines) override {
   ++Count;
 }
   };
@@ -252,21 +288,124 @@
 return Pos;
   };
 
-  std::vector Tokens{
-  {HighlightingKind::Variable,
-Range{CreatePosition(3, 8), CreatePosition(3, 12)}},
-  {HighlightingKind::Function,
-Range{CreatePosition(3, 4), CreatePosition(3, 7)}},
-  {HighlightingKind::Variable,
-Range{CreatePosition(1, 1), CreatePosition(1, 5)}}};
+  std::vector Tokens{
+  {3,
+   {{HighlightingKind::Variable,
+ Range{CreatePosition(3, 8), CreatePosition(3, 12)}},
+{HighlightingKind::Function,
+ Range{CreatePosition(3, 4), CreatePosition(3, 7),
+  {1,
+   {{HighlightingKind::Variable,
+ Range{CreatePosition(1, 1), CreatePosition(1, 5)};
   std::vector ActualResults =
   toSemanticHighlightingInformation(Tokens);
   std::vector ExpectedResults = {
-  {1, "AQAEAAA="},
-  {3, "CAAEAAAEAAMAAQ=="}};
+  {3, "CAAEAAAEAAMAAQ=="}, {1, "AQAEAAA="}};
   EXPECT_EQ(ActualResults, ExpectedResults);
 }
 
+TEST(SemanticHighlightin

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1125
+Old = std::move(FileToHighlightings[File]);
+FileToHighlightings[File] = Highlightings;
+  }

NIT: avoid copying (from `Highlightings` into the map) under a lock, make the 
copy outside the lock instead



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:408
+}
+
 } // namespace

Could you also add a separate test that checks diffs when the number of lines 
is getting smaller (i.e. taking `NLines` into account)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:408
+}
+
 } // namespace

ilya-biryukov wrote:
> Could you also add a separate test that checks diffs when the number of lines 
> is getting smaller (i.e. taking `NLines` into account)
I would expect this to be better handled outside `checkDiffedHighlights` to 
avoid over-generalizing this function. But up to you.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59637: [analyzer] Use the custom propagation rules and sinks in GenericTaintChecker

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In general, don't emit to stderr unless we either emit a warning/error about 
the incorrect configuration. As an experiment, what happens when you try to 
emit an error in the middle of the symbolic execution? You can retrieve a 
`DiagnosticsEngine` from any decl: `D->getASTContext().getDiagnostics()` (it's 
funny how you can retrieve almost all major manager objects if you try hard 
enough).




Comment at: clang/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:136
+  /// Check if tainted data is used as a custom sink's parameter.
+  static const char MsgCustomSink[];
+  bool checkCustomSinks(const CallExpr *CE, StringRef Name,

How about `llvm::StringLiteral`?



Comment at: clang/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:836
+   CheckerContext &C) const {
+  auto It = CustomSinks.find(Name);
+  if (It == CustomSinks.end())

Hmmm, how do we do with qualified names (`MyClass::generateTaint()`, `std::cin 
>>`)?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59637/new/

https://reviews.llvm.org/D59637



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59516: [analyzer] Add custom filter functions for GenericTaintChecker

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In general, the patch is looking alright, I'll take a second look later on. 
Don't mind my inlines too much, they are more directed towards the original 
code then your changes.




Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:53-56
+  void Profile(llvm::FoldingSetNodeID &ID) const {
+ID.AddInteger(Arg);
+ID.AddInteger(TagType);
+  }

Interesting, isn't this predefined for `std::pair`?



Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:474-476
+  const FunctionDecl *FDecl = C.getCalleeDecl(CE);
+  if (!FDecl || FDecl->getKind() != Decl::Function)
+return;

When do these happen? For implicit functions in C? 



Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:478-480
+  StringRef Name = C.getCalleeName(FDecl);
+  if (Name.empty())
+return;

And this? Lambdas maybe?



Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:560
 
-  for (unsigned ArgNum : TaintArgs) {
+  for (auto ArgTypePair : TaintArgs) {
+unsigned ArgNum = ArgTypePair.Arg;

Please add the full type name, else it isn't obvious why we don't take it as a 
const reference.



Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:561-562
+  for (auto ArgTypePair : TaintArgs) {
+unsigned ArgNum = ArgTypePair.Arg;
+TaintTagType TagType = ArgTypePair.TagType;
 // Special handling for the tainted return value.

We don't use `std::pair`, so we have descriptive field names, do we need these?



Comment at: lib/StaticAnalyzer/Checkers/Taint.h:25-28
 using TaintTagType = unsigned;
 
-static constexpr TaintTagType TaintTagGeneric = 0;
+static constexpr TaintTagType TaintTagNotTainted = 0;
+static constexpr TaintTagType TaintTagGeneric = 1;

Is there a **very** good reason behind us not using an `enum` instead?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59516/new/

https://reviews.llvm.org/D59516



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62688: [Analyzer] Iterator Checkers - Model `empty()` method of containers

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D62688#1606096 , 
@baloghadamsoftware wrote:

> In D62688#1549574 , @Szelethus wrote:
>
> > Hmm, an idea just popped into my head. I'm not sure whether we have a 
> > single checker that does so much complicated (and totally awesome) modeling 
> > as `IteratorChecker`.  What do you think about a debug checker similar to 
> > `debug.ExprInspection`, like `debug.IteratorInspection`?
>
>
> Good idea! However, I would do it in a way that we can reuse our existing 
> debug functions in the tests:
>
>   template  long clang_iterator_position(const Iter&);
>   template  const Cont& 
> clang_iterator_container(const Iter&);
>   template  long clang_container_begin(const Iter&);
>   template  long clang_container_end(const Iter&);
>
>
> Then we can nest calls for these functions into call of 
> `clang_analyzer_dump()`, `clang_analyzer_eval()`, `clang_analyzer_denote()` 
> etc.


Sounds awesome! I personally struggle a bit with these patches because the 
problem is so complex, I think this would help with reviewing tremendously.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62688/new/

https://reviews.llvm.org/D62688



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65263: [clangd] a prototype for triggering rename after extracting.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

In D65263#1606371 , @hokein wrote:

> I agree that doing rename after extraction is not an ideal approach (both 
> correctness and latency), there should be other better ways to achieve this. 
>  However as a LSP server, we may want to align with the community and other 
> language servers (typescript,  java) in order to provide consistent 
> refactoring experience across languages (vscode 
>  prefers to do extract 
> with a default name and rename afterwards).


Java and Typescript can pretty much guarantee (local) rename is fast and 
latency is never an issue for those languages.
Either approach seems to require LSP extensions. Pre-select seems to provide 
better UX , that's the reason I'm proposing to look in that direction.

> Note that this patch aims to implement a generic mechanism to perform a chain 
> of small refactorings (extract + rename is just one example), we still need 
> this no match which way we're going to perform.

Totally agree.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65263/new/

https://reviews.llvm.org/D65263



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65395: [clangd] Added a skeleton for a semantic highlighting feature to the vscode extension.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom added a comment.

In D65395#1607889 , @hokein wrote:

> The skeleton looks good, but apparently it does nothing (only enable the 
> feature), do you have a small working prototype?


I've got a prototype that colors all the highlightings red, but it would make 
the CL become quite big if I added that as well. This felt like a reasonable 
place to divide it. Do you want me to add that as well or should I keep it as 
2-3 CLs? (i.e. this -> TM scopes -> highlighting rendering)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65395/new/

https://reviews.llvm.org/D65395



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 212528.
jvikstrom marked an inline comment as done.
jvikstrom added a comment.

Copy outside lock.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -29,9 +29,7 @@
   return Tokens;
 }
 
-void checkHighlightings(llvm::StringRef Code) {
-  Annotations Test(Code);
-  auto AST = TestTU::withCode(Test.code()).build();
+std::vector getExpectedTokens(Annotations &Test) {
   static const std::map KindToString{
   {HighlightingKind::Variable, "Variable"},
   {HighlightingKind::Function, "Function"},
@@ -48,10 +46,47 @@
 Test.ranges(KindString.second), KindString.first);
 ExpectedTokens.insert(ExpectedTokens.end(), Toks.begin(), Toks.end());
   }
+  llvm::sort(ExpectedTokens);
+  return ExpectedTokens;
+}
+
+void checkHighlightings(llvm::StringRef Code) {
+  Annotations Test(Code);
+  auto AST = TestTU::withCode(Test.code()).build();
+  std::vector ActualTokens = getSemanticHighlightings(AST);
+  EXPECT_THAT(ActualTokens, getExpectedTokens(Test));
+}
+
+// Any annotations in OldCode and NewCode are converted into their corresponding
+// HighlightingToken. The tokens are diffed against each other. Any lines where
+// the tokens should diff must be marked with a ^ somewhere on that line in
+// NewCode. If there are diffs that aren't marked with ^ the test fails. The
+// test also fails if there are lines marked with ^ that don't differ.
+void checkDiffedHighlights(llvm::StringRef OldCode, llvm::StringRef NewCode) {
+  Annotations OldTest(OldCode);
+  Annotations NewTest(NewCode);
+  std::vector OldTokens = getExpectedTokens(OldTest);
+  std::vector NewTokens = getExpectedTokens(NewTest);
+
+  llvm::DenseMap> ExpectedLines;
+  for (const Position &Point : NewTest.points()) {
+ExpectedLines[Point.line]; // Default initialize to an empty line. Tokens
+   // are inserted on these lines later.
+  }
+  std::vector ExpectedLinePairHighlighting;
+  for (const HighlightingToken &Token : NewTokens) {
+auto It = ExpectedLines.find(Token.R.start.line);
+if (It != ExpectedLines.end())
+  It->second.push_back(Token);
+  }
+  for (auto &LineTokens : ExpectedLines)
+ExpectedLinePairHighlighting.push_back(
+{LineTokens.first, LineTokens.second});
 
-  auto ActualTokens = getSemanticHighlightings(AST);
-  EXPECT_THAT(ActualTokens, testing::UnorderedElementsAreArray(ExpectedTokens))
-   << "Inputs is:\n" << Code;
+  std::vector ActualDiffed =
+  diffHighlightings(NewTokens, OldTokens, NewCode.count('\n'));
+  EXPECT_THAT(ActualDiffed,
+  testing::UnorderedElementsAreArray(ExpectedLinePairHighlighting));
 }
 
 TEST(SemanticHighlighting, GetsCorrectTokens) {
@@ -226,8 +261,9 @@
 std::atomic Count = {0};
 
 void onDiagnosticsReady(PathRef, std::vector) override {}
-void onHighlightingsReady(
-PathRef File, std::vector Highlightings) override {
+void onHighlightingsReady(PathRef File,
+  std::vector Highlightings,
+  int NLines) override {
   ++Count;
 }
   };
@@ -252,21 +288,124 @@
 return Pos;
   };
 
-  std::vector Tokens{
-  {HighlightingKind::Variable,
-Range{CreatePosition(3, 8), CreatePosition(3, 12)}},
-  {HighlightingKind::Function,
-Range{CreatePosition(3, 4), CreatePosition(3, 7)}},
-  {HighlightingKind::Variable,
-Range{CreatePosition(1, 1), CreatePosition(1, 5)}}};
+  std::vector Tokens{
+  {3,
+   {{HighlightingKind::Variable,
+ Range{CreatePosition(3, 8), CreatePosition(3, 12)}},
+{HighlightingKind::Function,
+ Range{CreatePosition(3, 4), CreatePosition(3, 7),
+  {1,
+   {{HighlightingKind::Variable,
+ Range{CreatePosition(1, 1), CreatePosition(1, 5)};
   std::vector ActualResults =
   toSemanticHighlightingInformation(Tokens);
   std::vector ExpectedResults = {
-  {1, "AQAEAAA="},
-  {3, "CAAEAAAEAAMAAQ=="}};
+  {3, "CAAEAAAEAAMAAQ=="}, {1, "AQAEAAA="}};
   EXPECT_EQ(ActualResults, ExpectedResults);
 }
 
+TEST(SemanticHighlighting, HighlightingDiffer) {
+  s

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom added inline comments.



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:408
+}
+
 } // namespace

ilya-biryukov wrote:
> ilya-biryukov wrote:
> > Could you also add a separate test that checks diffs when the number of 
> > lines is getting smaller (i.e. taking `NLines` into account)
> I would expect this to be better handled outside `checkDiffedHighlights` to 
> avoid over-generalizing this function. But up to you.
That's what this test does: 

```
{
R"(
$Class[[A]]
$Variable[[A]]
$Class[[A]]
$Variable[[A]]
  )",
R"(
$Class[[A]]
$Variable[[A]]
  )"},
```

But do you mean I should do a testcase like:



```
{
R"(
$Class[[A]]
$Variable[[A]]
$Class[[A]]
$Variable[[A]]
  )",
R"(
$Class[[A]]
$Variable[[A]]
$Class[[A]]
$Variable[[A]]
  )"},
```
And just set NLines = 2 instead when doing the diffing?



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1125
+Old = std::move(FileToHighlightings[File]);
+FileToHighlightings[File] = Highlightings;
+  }

ilya-biryukov wrote:
> NIT: avoid copying (from `Highlightings` into the map) under a lock, make the 
> copy outside the lock instead
I think we can even avoid copy, since we only use the `Highlightings` for 
calculating the diff.

Maybe just 

```
{
std::lock_guard Lock(HighlightingsMutex);
Old = std::move(FileToHighlightings[File]);
}
// calculate the diff.
{  
 std::lock_guard Lock(HighlightingsMutex);
 FileToHighlightings[File] = std::move(Highlightings);
}
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62893: [Analyzer] Iterator Checkers - Make range errors and invalidated access fatal

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus accepted this revision.
Szelethus added a comment.
This revision is now accepted and ready to land.

Makes sense! But, does any of the test cases actually test *this* particular 
change?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62893/new/

https://reviews.llvm.org/D62893



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 212536.
sammccall added a comment.

Improve comments in SelectedTokens.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65486/new/

https://reviews.llvm.org/D65486

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/Selection.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp

Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -23,16 +23,16 @@
   Annotations Test(MarkedCode);
   switch (Test.points().size()) {
   case 1: // Point selection.
-return SelectionTree(AST.getASTContext(),
+return SelectionTree(AST.getASTContext(), AST.getTokens(),
  cantFail(positionToOffset(Test.code(), Test.point(;
   case 2: // Range selection.
 return SelectionTree(
-AST.getASTContext(),
+AST.getASTContext(), AST.getTokens(),
 cantFail(positionToOffset(Test.code(), Test.points()[0])),
 cantFail(positionToOffset(Test.code(), Test.points()[1])));
   default:
 ADD_FAILURE() << "Expected 1-2 points for selection.\n" << MarkedCode;
-return SelectionTree(AST.getASTContext(), 0u, 0u);
+return SelectionTree(AST.getASTContext(), AST.getTokens(), 0u, 0u);
   }
 }
 
@@ -219,6 +219,9 @@
   {"void foo() { [[foo^]] (); }", "DeclRefExpr"},
   {"int bar; void foo() [[{ foo (); }]]^", "CompoundStmt"},
 
+  // Ignores whitespace, comments, and semicolons in the selection.
+  {"void foo() { [[foo^()]]; /*comment*/^}", "CallExpr"},
+
   // Tricky case: FunctionTypeLoc in FunctionDecl has a hole in it.
   {"[[^void]] foo();", "BuiltinTypeLoc"},
   {"[[void foo^()]];", "FunctionProtoTypeLoc"},
Index: clang-tools-extra/clangd/refactor/Tweak.cpp
===
--- clang-tools-extra/clangd/refactor/Tweak.cpp
+++ clang-tools-extra/clangd/refactor/Tweak.cpp
@@ -41,7 +41,7 @@
 Tweak::Selection::Selection(ParsedAST &AST, unsigned RangeBegin,
 unsigned RangeEnd)
 : AST(AST), SelectionBegin(RangeBegin), SelectionEnd(RangeEnd),
-  ASTSelection(AST.getASTContext(), RangeBegin, RangeEnd) {
+  ASTSelection(AST.getASTContext(), AST.getTokens(), RangeBegin, RangeEnd) {
   auto &SM = AST.getSourceManager();
   Code = SM.getBufferData(SM.getMainFileID());
   Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
Index: clang-tools-extra/clangd/Selection.h
===
--- clang-tools-extra/clangd/Selection.h
+++ clang-tools-extra/clangd/Selection.h
@@ -35,6 +35,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SELECTION_H
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/PrettyPrinter.h"
+#include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/SmallVector.h"
 
 namespace clang {
@@ -56,8 +57,9 @@
 //
 // SelectionTree tries to behave sensibly in the presence of macros, but does
 // not model any preprocessor concepts: the output is a subset of the AST.
-// Currently comments, directives etc are treated as part of the lexically
-// containing AST node, (though we may want to change this in future).
+//
+// Comments, directives and whitespace are completely ignored.
+// Semicolons are also ignored, as the AST generally does not model them well.
 //
 // The SelectionTree owns the Node structures, but the ASTNode attributes
 // point back into the AST it was constructed with.
@@ -66,11 +68,13 @@
   // Creates a selection tree at the given byte offset in the main file.
   // This is approximately equivalent to a range of one character.
   // (Usually, the character to the right of Offset, sometimes to the left).
-  SelectionTree(ASTContext &AST, unsigned Offset);
+  SelectionTree(ASTContext &AST, const syntax::TokenBuffer &Tokens,
+unsigned Offset);
   // Creates a selection tree for the given range in the main file.
   // The range includes bytes [Start, End).
   // If Start == End, uses the same heuristics as SelectionTree(AST, Start).
-  SelectionTree(ASTContext &AST, unsigned Start, unsigned End);
+  SelectionTree(ASTContext &AST, const syntax::TokenBuffer &Tokens,
+unsigned Start, unsigned End);
 
   // Describes to what extent an AST node is covered by the selection.
   enum Selection {
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -17,6 +17,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
+#include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Sup

[PATCH] D62895: [Analyzer] Iterator Checkers - Check and simulate `std::advance`, `std::prev` and `std::next`

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Again, this a place where a debugging functionality would be awesome to 
precisely observe the change being made. I also noticed that `IteratorChecker` 
and related classes don't have any dump methods, maybe that is worth investing 
into as well?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62895/new/

https://reviews.llvm.org/D62895



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367399 - [RISCV] Add support for floating point registers in inlineasm

[Simon Cook via cfe-commits]

Author: simoncook
Date: Wed Jul 31 02:12:00 2019
New Revision: 367399

URL: http://llvm.org/viewvc/llvm-project?rev=367399&view=rev
Log:
[RISCV] Add support for floating point registers in inlineasm

This adds support for parsing/emitting in IR the floating-point RISC-V
registers in inline assembly clobber lists.

Differential Revision: https://reviews.llvm.org/D64737

Added:
cfe/trunk/test/Sema/riscv-asm.c
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp

Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=367399&r1=367398&r2=367399&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Wed Jul 31 02:12:00 2019
@@ -19,23 +19,38 @@ using namespace clang::targets;
 
 ArrayRef RISCVTargetInfo::getGCCRegNames() const {
   static const char *const GCCRegNames[] = {
+  // Integer registers
   "x0",  "x1",  "x2",  "x3",  "x4",  "x5",  "x6",  "x7",
   "x8",  "x9",  "x10", "x11", "x12", "x13", "x14", "x15",
   "x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23",
-  "x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31"};
+  "x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31",
+
+  // Floating point registers
+  "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7",
+  "f8",  "f9",  "f10", "f11", "f12", "f13", "f14", "f15",
+  "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
+  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"};
   return llvm::makeArrayRef(GCCRegNames);
 }
 
 ArrayRef RISCVTargetInfo::getGCCRegAliases() const {
   static const TargetInfo::GCCRegAlias GCCRegAliases[] = {
-  {{"zero"}, "x0"}, {{"ra"}, "x1"},  {{"sp"}, "x2"},   {{"gp"}, "x3"},
-  {{"tp"}, "x4"},   {{"t0"}, "x5"},  {{"t1"}, "x6"},   {{"t2"}, "x7"},
-  {{"s0"}, "x8"},   {{"s1"}, "x9"},  {{"a0"}, "x10"},  {{"a1"}, "x11"},
-  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x14"},  {{"a5"}, "x15"},
-  {{"a6"}, "x16"},  {{"a7"}, "x17"}, {{"s2"}, "x18"},  {{"s3"}, "x19"},
-  {{"s4"}, "x20"},  {{"s5"}, "x21"}, {{"s6"}, "x22"},  {{"s7"}, "x23"},
-  {{"s8"}, "x24"},  {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},
-  {{"t3"}, "x28"},  {{"t4"}, "x29"}, {{"t5"}, "x30"},  {{"t6"}, "x31"}};
+  {{"zero"}, "x0"}, {{"ra"}, "x1"},   {{"sp"}, "x2"},{{"gp"}, "x3"},
+  {{"tp"}, "x4"},   {{"t0"}, "x5"},   {{"t1"}, "x6"},{{"t2"}, "x7"},
+  {{"s0"}, "x8"},   {{"s1"}, "x9"},   {{"a0"}, "x10"},   {{"a1"}, "x11"},
+  {{"a2"}, "x12"},  {{"a3"}, "x13"},  {{"a4"}, "x14"},   {{"a5"}, "x15"},
+  {{"a6"}, "x16"},  {{"a7"}, "x17"},  {{"s2"}, "x18"},   {{"s3"}, "x19"},
+  {{"s4"}, "x20"},  {{"s5"}, "x21"},  {{"s6"}, "x22"},   {{"s7"}, "x23"},
+  {{"s8"}, "x24"},  {{"s9"}, "x25"},  {{"s10"}, "x26"},  {{"s11"}, "x27"},
+  {{"t3"}, "x28"},  {{"t4"}, "x29"},  {{"t5"}, "x30"},   {{"t6"}, "x31"},
+  {{"ft0"}, "f0"},  {{"ft1"}, "f1"},  {{"ft2"}, "f2"},   {{"ft3"}, "f3"},
+  {{"ft4"}, "f4"},  {{"ft5"}, "f5"},  {{"ft6"}, "f6"},   {{"ft7"}, "f7"},
+  {{"fs0"}, "f8"},  {{"fs1"}, "f9"},  {{"fa0"}, "f10"},  {{"fa1"}, "f11"},
+  {{"fa2"}, "f12"}, {{"fa3"}, "f13"}, {{"fa4"}, "f14"},  {{"fa5"}, "f15"},
+  {{"fa6"}, "f16"}, {{"fa7"}, "f17"}, {{"fs2"}, "f18"},  {{"fs3"}, "f19"},
+  {{"fs4"}, "f20"}, {{"fs5"}, "f21"}, {{"fs6"}, "f22"},  {{"fs7"}, "f23"},
+  {{"fs8"}, "f24"}, {{"fs9"}, "f25"}, {{"fs10"}, "f26"}, {{"fs11"}, "f27"},
+  {{"ft8"}, "f28"}, {{"ft9"}, "f29"}, {{"ft10"}, "f30"}, {{"ft11"}, 
"f31"}};
   return llvm::makeArrayRef(GCCRegAliases);
 }
 

Added: cfe/trunk/test/Sema/riscv-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/riscv-asm.c?rev=367399&view=auto
==
--- cfe/trunk/test/Sema/riscv-asm.c (added)
+++ cfe/trunk/test/Sema/riscv-asm.c Wed Jul 31 02:12:00 2019
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 %s -triple riscv32 -verify -fsyntax-only
+// RUN: %clang_cc1 %s -triple riscv64 -verify -fsyntax-only
+
+// expected-no-diagnostics
+
+void i (void) {
+  asm volatile ("" ::: "x0",  "x1",  "x2",  "x3",  "x4",  "x5",  "x6",  "x7");
+  asm volatile ("" ::: "x8",  "x9",  "x10", "x11", "x12", "x13", "x14", "x15");
+  asm volatile ("" ::: "x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23");
+  asm volatile ("" ::: "x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31");
+
+  asm volatile ("" ::: "zero", "ra", "sp",  "gp",  "tp", "t0", "t1", "t2");
+  asm volatile ("" ::: "s0",   "s1", "a0",  "a1",  "a2", "a3", "a4", "a5");
+  asm volatile ("" ::: "a6",   "a7", "s2",  "s3",  "s4", "s5", "s6", "s7");
+  asm volatile ("" ::: "s8",   "s9", "s10", "s11", "t3", "t4", "t5", "t6");
+}
+
+void f (void) {
+  asm volatile ("" ::: "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7");
+  asm volatile ("" ::: "f8",  "f9",

[PATCH] D64737: RISCV: Add support for floating point registers in inlineasm

[Simon Cook via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367399: [RISCV] Add support for floating point registers in 
inlineasm (authored by simoncook, committed by ).
Herald added subscribers: llvm-commits, s.egerton.
Herald added a project: LLVM.

Changed prior to commit:
  https://reviews.llvm.org/D64737?vs=209839&id=212540#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64737/new/

https://reviews.llvm.org/D64737

Files:
  cfe/trunk/lib/Basic/Targets/RISCV.cpp
  cfe/trunk/test/Sema/riscv-asm.c


Index: cfe/trunk/test/Sema/riscv-asm.c
===
--- cfe/trunk/test/Sema/riscv-asm.c
+++ cfe/trunk/test/Sema/riscv-asm.c
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 %s -triple riscv32 -verify -fsyntax-only
+// RUN: %clang_cc1 %s -triple riscv64 -verify -fsyntax-only
+
+// expected-no-diagnostics
+
+void i (void) {
+  asm volatile ("" ::: "x0",  "x1",  "x2",  "x3",  "x4",  "x5",  "x6",  "x7");
+  asm volatile ("" ::: "x8",  "x9",  "x10", "x11", "x12", "x13", "x14", "x15");
+  asm volatile ("" ::: "x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23");
+  asm volatile ("" ::: "x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31");
+
+  asm volatile ("" ::: "zero", "ra", "sp",  "gp",  "tp", "t0", "t1", "t2");
+  asm volatile ("" ::: "s0",   "s1", "a0",  "a1",  "a2", "a3", "a4", "a5");
+  asm volatile ("" ::: "a6",   "a7", "s2",  "s3",  "s4", "s5", "s6", "s7");
+  asm volatile ("" ::: "s8",   "s9", "s10", "s11", "t3", "t4", "t5", "t6");
+}
+
+void f (void) {
+  asm volatile ("" ::: "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7");
+  asm volatile ("" ::: "f8",  "f9",  "f10", "f11", "f12", "f13", "f14", "f15");
+  asm volatile ("" ::: "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23");
+  asm volatile ("" ::: "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31");
+
+  asm volatile ("" ::: "ft0", "ft1", "ft2",  "ft3",  "ft4", "ft5", "ft6",  
"ft7");
+  asm volatile ("" ::: "fs0", "fs1", "fa0",  "fa1",  "fa2", "fa3", "fa4",  
"fa5");
+  asm volatile ("" ::: "fa6", "fa7", "fs2",  "fs3",  "fs4", "fs5", "fs6",  
"fs7");
+  asm volatile ("" ::: "fs8", "fs9", "fs10", "fs11", "ft8", "ft9", "ft10", 
"ft11");
+}
Index: cfe/trunk/lib/Basic/Targets/RISCV.cpp
===
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp
@@ -19,23 +19,38 @@
 
 ArrayRef RISCVTargetInfo::getGCCRegNames() const {
   static const char *const GCCRegNames[] = {
+  // Integer registers
   "x0",  "x1",  "x2",  "x3",  "x4",  "x5",  "x6",  "x7",
   "x8",  "x9",  "x10", "x11", "x12", "x13", "x14", "x15",
   "x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23",
-  "x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31"};
+  "x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31",
+
+  // Floating point registers
+  "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7",
+  "f8",  "f9",  "f10", "f11", "f12", "f13", "f14", "f15",
+  "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
+  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"};
   return llvm::makeArrayRef(GCCRegNames);
 }
 
 ArrayRef RISCVTargetInfo::getGCCRegAliases() const {
   static const TargetInfo::GCCRegAlias GCCRegAliases[] = {
-  {{"zero"}, "x0"}, {{"ra"}, "x1"},  {{"sp"}, "x2"},   {{"gp"}, "x3"},
-  {{"tp"}, "x4"},   {{"t0"}, "x5"},  {{"t1"}, "x6"},   {{"t2"}, "x7"},
-  {{"s0"}, "x8"},   {{"s1"}, "x9"},  {{"a0"}, "x10"},  {{"a1"}, "x11"},
-  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x14"},  {{"a5"}, "x15"},
-  {{"a6"}, "x16"},  {{"a7"}, "x17"}, {{"s2"}, "x18"},  {{"s3"}, "x19"},
-  {{"s4"}, "x20"},  {{"s5"}, "x21"}, {{"s6"}, "x22"},  {{"s7"}, "x23"},
-  {{"s8"}, "x24"},  {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},
-  {{"t3"}, "x28"},  {{"t4"}, "x29"}, {{"t5"}, "x30"},  {{"t6"}, "x31"}};
+  {{"zero"}, "x0"}, {{"ra"}, "x1"},   {{"sp"}, "x2"},{{"gp"}, "x3"},
+  {{"tp"}, "x4"},   {{"t0"}, "x5"},   {{"t1"}, "x6"},{{"t2"}, "x7"},
+  {{"s0"}, "x8"},   {{"s1"}, "x9"},   {{"a0"}, "x10"},   {{"a1"}, "x11"},
+  {{"a2"}, "x12"},  {{"a3"}, "x13"},  {{"a4"}, "x14"},   {{"a5"}, "x15"},
+  {{"a6"}, "x16"},  {{"a7"}, "x17"},  {{"s2"}, "x18"},   {{"s3"}, "x19"},
+  {{"s4"}, "x20"},  {{"s5"}, "x21"},  {{"s6"}, "x22"},   {{"s7"}, "x23"},
+  {{"s8"}, "x24"},  {{"s9"}, "x25"},  {{"s10"}, "x26"},  {{"s11"}, "x27"},
+  {{"t3"}, "x28"},  {{"t4"}, "x29"},  {{"t5"}, "x30"},   {{"t6"}, "x31"},
+  {{"ft0"}, "f0"},  {{"ft1"}, "f1"},  {{"ft2"}, "f2"},   {{"ft3"}, "f3"},
+  {{"ft4"}, "f4"},  {{"ft5"}, "f5"},  {{"ft6"}, "f6"},   {{"ft7"}, "f7"},
+  {{"fs0"}, "f8"},  {{"fs1"}, "f9"},  {{"fa0"}, "f10"},  {{"fa1"}, "f11"},
+  {{"fa2"}, "f12"}, {{"fa3"}, "f13"}, {{"fa4"}, "f14"},  {{"fa5"}, "f15"},
+  {{"fa6"}, "f16"}, {{"fa7"}, "f17"}, {{"fs2"}, "f18

[PATCH] D59637: [analyzer] Use the custom propagation rules and sinks in GenericTaintChecker

[Borsik Gábor via Phabricator via cfe-commits]

boga95 marked 2 inline comments as done.
boga95 added a comment.

I think it shouldn't give compile error in case of incorrect configuration now 
(maybe warning) because:

- Without qualified names, I can create a code which cannot be configured 
properly.



- It can throw an error without configuration, for example:

  void read(int*); // There is an existing propagation rule for it

I suggest to let it unchanged now, and I will change it when the checker can 
handle qualified names.
On the other hand, I think we should make this type of error configurable (from 
the command line). So the user can select between warnings and errors.




Comment at: clang/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:836
+   CheckerContext &C) const {
+  auto It = CustomSinks.find(Name);
+  if (It == CustomSinks.end())

Szelethus wrote:
> Hmmm, how do we do with qualified names (`MyClass::generateTaint()`, 
> `std::cin >>`)?
These patches focus on C style functions. I have implemented the uses of 
qualified names, but I intended to make a separate patch for that. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59637/new/

https://reviews.llvm.org/D59637



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367403 - [RISCV] Support 'f' Inline Assembly Constraint

[Sam Elliott via cfe-commits]

Author: lenary
Date: Wed Jul 31 02:45:55 2019
New Revision: 367403

URL: http://llvm.org/viewvc/llvm-project?rev=367403&view=rev
Log:
[RISCV] Support 'f' Inline Assembly Constraint

Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).

This patch adds support in both the clang frontend, and LLVM itself.

Reviewers: asb, lewis-revill

Reviewed By: asb

Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, 
kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, 
MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, 
s.egerton, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D65500

Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/test/CodeGen/riscv-inline-asm.c

Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=367403&r1=367402&r2=367403&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Wed Jul 31 02:45:55 2019
@@ -71,6 +71,10 @@ bool RISCVTargetInfo::validateAsmConstra
 // A 5-bit unsigned immediate for CSR access instructions.
 Info.setRequiresImmediate(0, 31);
 return true;
+  case 'f':
+// A floating-point register.
+Info.setAllowsRegister();
+return true;
   }
 }
 

Modified: cfe/trunk/test/CodeGen/riscv-inline-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv-inline-asm.c?rev=367403&r1=367402&r2=367403&view=diff
==
--- cfe/trunk/test/CodeGen/riscv-inline-asm.c (original)
+++ cfe/trunk/test/CodeGen/riscv-inline-asm.c Wed Jul 31 02:45:55 2019
@@ -26,3 +26,15 @@ void test_K() {
 // CHECK: call void asm sideeffect "", "K"(i32 0)
   asm volatile ("" :: "K"(0));
 }
+
+float f;
+double d;
+void test_f() {
+// CHECK-LABEL: define void @test_f()
+// CHECK: [[FLT_ARG:%[a-zA-Z_0-9]+]] = load float, float* @f
+// CHECK: call void asm sideeffect "", "f"(float [[FLT_ARG]])
+  asm volatile ("" :: "f"(f));
+// CHECK: [[FLT_ARG:%[a-zA-Z_0-9]+]] = load double, double* @d
+// CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
+  asm volatile ("" :: "f"(d));
+}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r367406 - [Clangd] NFC: Added FIXME in ExtractVariable tests

[Shaurya Gupta via cfe-commits]

Author: sureyeaah
Date: Wed Jul 31 03:08:29 2019
New Revision: 367406

URL: http://llvm.org/viewvc/llvm-project?rev=367406&view=rev
Log:
[Clangd] NFC: Added FIXME in ExtractVariable tests

Modified:
clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp

Modified: clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp?rev=367406&r1=367405&r2=367406&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp Wed Jul 31 03:08:29 
2019
@@ -419,6 +419,11 @@ TEST(TweakTest, ExtractVariable) {
  void f(int a) {
PLUS([[1+a]]);
  })cpp",
+  /*FIXME: It should be extracted like this.
+   R"cpp(#define PLUS(x) x++
+ void f(int a) {
+   auto dummy = 1+a; int y = PLUS(dummy);
+ })cpp"},*/
R"cpp(#define PLUS(x) x++
  void f(int a) {
auto dummy = PLUS(1+a); dummy;
@@ -429,9 +434,9 @@ TEST(TweakTest, ExtractVariable) {
if(1)
 LOOP(5 + [[3]])
  })cpp",
-   /*FIXME: It should be extracted like this. SelectionTree needs to be
+  /*FIXME: It should be extracted like this. SelectionTree needs to be
 * fixed for macros.
- R"cpp(#define LOOP(x) while (1) {a = x;}
+   R"cpp(#define LOOP(x) while (1) {a = x;}
void f(int a) {
  auto dummy = 3; if(1)
   LOOP(5 + dummy)


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64799: [Sema] Emit diagnostics for uncorrected delayed typos at the end of TU

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

An experiment with popping on expression evaluation context failed, I couldn't 
find a good way to fix the problems described above.
Typo correction can and will run after the evaluation context where expression 
created is popped and the diagnostic we produce depends on the results of typo 
correction.
Emitting diagnostics on some, but not all context pops could be an option, but 
classifying those seems to be hard, would require looking closely at every expr 
eval context push.

> Failing that, I can live with this landing as-is, but delaying these 
> diagnostics to the end of the file is going to result in a bad user 
> experience whenever it happens -- and I suspect it'll start happening 
> significantly more than the assert currently fails, because we'll no longer 
> have this assertion forcing people to call `CorrectDelayedTyposInExpr` when 
> discarding an expression.

In practice, this assertion is not even checked most of the time. As mentioned 
earlier, it only fires when running `clang -cc1` is triggered explicitly 
**without** `-disable-free` (and driver passes `-disable-free` by default).
We ended up in a situation when this assertion was not firing for awhile; 
`clangd` and `libclang` crash because of this assertion and nobody else notices 
because `clang` won't crash and won't produce the errors either.

I'm happy to either emit or leave out those errors, but I think we should 
absolutely get rid of assertion in the Sema destructor that only fires in 
`clang -cc1` and source-level tools.
Placing it at some other place that would help to discover all missing calls to 
`CorrectTypos` to fix typo correction seems ok. However, this change is aimed 
at unbreaking `libclang` and `clangd` and not fixing typo correction (it looks 
like a much harder problem).

@rsmith two options for this patch seem to be:

- silently ignore the errors (current behavior),
- show them to the user at the end of TU (can result in bad UX, but we won't 
drop any errors on the floor).

Which one do you think we should prefer?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64799/new/

https://reviews.llvm.org/D64799



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65500: [RISCV] Support 'f' Inline Assembly Constraint

[Sam Elliott via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367403: [RISCV] Support 'f' Inline Assembly 
Constraint (authored by lenary, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D65500?vs=212513&id=212543#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65500/new/

https://reviews.llvm.org/D65500

Files:
  cfe/trunk/lib/Basic/Targets/RISCV.cpp
  cfe/trunk/test/CodeGen/riscv-inline-asm.c
  llvm/trunk/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/trunk/lib/Target/RISCV/RISCVISelLowering.h
  llvm/trunk/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
  llvm/trunk/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
  llvm/trunk/test/CodeGen/RISCV/inline-asm-invalid.ll

Index: llvm/trunk/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
===
--- llvm/trunk/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
+++ llvm/trunk/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
@@ -0,0 +1,34 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+f -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv64 -mattr=+f -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV64F %s
+
+@gf = external global float
+
+define float @constraint_f_float(float %a) nounwind {
+; RV32F-LABEL: constraint_f_float:
+; RV32F:   # %bb.0:
+; RV32F-NEXT:fmv.w.x ft0, a0
+; RV32F-NEXT:lui a0, %hi(gf)
+; RV32F-NEXT:flw ft1, %lo(gf)(a0)
+; RV32F-NEXT:#APP
+; RV32F-NEXT:fadd.s ft0, ft0, ft1
+; RV32F-NEXT:#NO_APP
+; RV32F-NEXT:fmv.x.w a0, ft0
+; RV32F-NEXT:ret
+;
+; RV64F-LABEL: constraint_f_float:
+; RV64F:   # %bb.0:
+; RV64F-NEXT:fmv.w.x ft0, a0
+; RV64F-NEXT:lui a0, %hi(gf)
+; RV64F-NEXT:flw ft1, %lo(gf)(a0)
+; RV64F-NEXT:#APP
+; RV64F-NEXT:fadd.s ft0, ft0, ft1
+; RV64F-NEXT:#NO_APP
+; RV64F-NEXT:fmv.x.w a0, ft0
+; RV64F-NEXT:ret
+  %1 = load float, float* @gf
+  %2 = tail call float asm "fadd.s $0, $1, $2", "=f,f,f"(float %a, float %1)
+  ret float %2
+}
Index: llvm/trunk/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
===
--- llvm/trunk/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
+++ llvm/trunk/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
@@ -0,0 +1,40 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+d -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv64 -mattr=+d -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV64F %s
+
+@gd = external global double
+
+define double @constraint_f_double(double %a) nounwind {
+; RV32F-LABEL: constraint_f_double:
+; RV32F:   # %bb.0:
+; RV32F-NEXT:addi sp, sp, -16
+; RV32F-NEXT:sw a0, 8(sp)
+; RV32F-NEXT:sw a1, 12(sp)
+; RV32F-NEXT:fld ft0, 8(sp)
+; RV32F-NEXT:lui a0, %hi(gd)
+; RV32F-NEXT:fld ft1, %lo(gd)(a0)
+; RV32F-NEXT:#APP
+; RV32F-NEXT:fadd.d ft0, ft0, ft1
+; RV32F-NEXT:#NO_APP
+; RV32F-NEXT:fsd ft0, 8(sp)
+; RV32F-NEXT:lw a0, 8(sp)
+; RV32F-NEXT:lw a1, 12(sp)
+; RV32F-NEXT:addi sp, sp, 16
+; RV32F-NEXT:ret
+;
+; RV64F-LABEL: constraint_f_double:
+; RV64F:   # %bb.0:
+; RV64F-NEXT:fmv.d.x ft0, a0
+; RV64F-NEXT:lui a0, %hi(gd)
+; RV64F-NEXT:fld ft1, %lo(gd)(a0)
+; RV64F-NEXT:#APP
+; RV64F-NEXT:fadd.d ft0, ft0, ft1
+; RV64F-NEXT:#NO_APP
+; RV64F-NEXT:fmv.x.d a0, ft0
+; RV64F-NEXT:ret
+  %1 = load double, double* @gd
+  %2 = tail call double asm "fadd.d $0, $1, $2", "=f,f,f"(double %a, double %1)
+  ret double %2
+}
Index: llvm/trunk/test/CodeGen/RISCV/inline-asm-invalid.ll
===
--- llvm/trunk/test/CodeGen/RISCV/inline-asm-invalid.ll
+++ llvm/trunk/test/CodeGen/RISCV/inline-asm-invalid.ll
@@ -22,3 +22,11 @@
   tail call void asm sideeffect "csrwi mstatus, $0", "K"(i32 -1)
   ret void
 }
+
+define void @constraint_f() nounwind {
+; CHECK: error: couldn't allocate input reg for constraint 'f'
+  tail call void asm "fadd.s fa0, fa0, $0", "f"(float 0.0)
+; CHECK: error: couldn't allocate input reg for constraint 'f'
+  tail call void asm "fadd.d fa0, fa0, $0", "f"(double 0.0)
+  ret void
+}
Index: llvm/trunk/lib/Target/RISCV/RISCVISelLowering.cpp
===
--- llvm/trunk/lib/Target/RISCV/RISCVISelLowering.cpp
+++ llvm/trunk/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -2397,6 +2397,21 @@
   return nullptr;
 }
 
+/// getConstraintType - Given a constraint letter, return the type of
+/// constraint it is for this target.
+RISCVTargetLowering::ConstraintType
+RISCVTargetLowering::getConstraintType(StringRef Constraint) const {
+  if (Constraint.size() == 1) {
+s

[PATCH] D65500: [RISCV] Support 'f' Inline Assembly Constraint

[Sam Elliott via Phabricator via cfe-commits]

lenary created this revision.
lenary added reviewers: asb, lewis-revill.
Herald added subscribers: llvm-commits, cfe-commits, s.egerton, Jim, benna, 
psnobl, jocewei, PkmX, rkruppe, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, MaskRay, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, 
apazos, simoncook, johnrusso, rbar, hiraditya.
Herald added projects: clang, LLVM.

This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).

This patch adds support in both the clang frontend, and LLVM itself.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65500

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/test/CodeGen/riscv-inline-asm.c
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
  llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
  llvm/test/CodeGen/RISCV/inline-asm-invalid.ll

Index: llvm/test/CodeGen/RISCV/inline-asm-invalid.ll
===
--- llvm/test/CodeGen/RISCV/inline-asm-invalid.ll
+++ llvm/test/CodeGen/RISCV/inline-asm-invalid.ll
@@ -22,3 +22,11 @@
   tail call void asm sideeffect "csrwi mstatus, $0", "K"(i32 -1)
   ret void
 }
+
+define void @constraint_f() nounwind {
+; CHECK: error: couldn't allocate output register for constraint 'f'
+  %1 = tail call float asm "fadd.s $0, $1, $2", "=f,f,f"(float 0.0, float 1.0)
+; CHECK: error: couldn't allocate output register for constraint 'f'
+  %2 = tail call double asm "fadd.d $0, $1, $2", "=f,f,f"(double 0.0, double 1.0)
+  ret void
+}
Index: llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
@@ -0,0 +1,34 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+f -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv64 -mattr=+f -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV64F %s
+
+@gf = external global float
+
+define float @constraint_f_float(float %a) nounwind {
+; RV32F-LABEL: constraint_f_float:
+; RV32F:   # %bb.0:
+; RV32F-NEXT:fmv.w.x ft0, a0
+; RV32F-NEXT:lui a0, %hi(gf)
+; RV32F-NEXT:flw ft1, %lo(gf)(a0)
+; RV32F-NEXT:#APP
+; RV32F-NEXT:fadd.s ft0, ft0, ft1
+; RV32F-NEXT:#NO_APP
+; RV32F-NEXT:fmv.x.w a0, ft0
+; RV32F-NEXT:ret
+;
+; RV64F-LABEL: constraint_f_float:
+; RV64F:   # %bb.0:
+; RV64F-NEXT:fmv.w.x ft0, a0
+; RV64F-NEXT:lui a0, %hi(gf)
+; RV64F-NEXT:flw ft1, %lo(gf)(a0)
+; RV64F-NEXT:#APP
+; RV64F-NEXT:fadd.s ft0, ft0, ft1
+; RV64F-NEXT:#NO_APP
+; RV64F-NEXT:fmv.x.w a0, ft0
+; RV64F-NEXT:ret
+  %1 = load float, float* @gf
+  %2 = tail call float asm "fadd.s $0, $1, $2", "=f,f,f"(float %a, float %1)
+  ret float %2
+}
Index: llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
@@ -0,0 +1,40 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+d -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv64 -mattr=+d -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV64F %s
+
+@gd = external global double
+
+define double @constraint_f_double(double %a) nounwind {
+; RV32F-LABEL: constraint_f_double:
+; RV32F:   # %bb.0:
+; RV32F-NEXT:addi sp, sp, -16
+; RV32F-NEXT:sw a0, 8(sp)
+; RV32F-NEXT:sw a1, 12(sp)
+; RV32F-NEXT:fld ft0, 8(sp)
+; RV32F-NEXT:lui a0, %hi(gd)
+; RV32F-NEXT:fld ft1, %lo(gd)(a0)
+; RV32F-NEXT:#APP
+; RV32F-NEXT:fadd.d ft0, ft0, ft1
+; RV32F-NEXT:#NO_APP
+; RV32F-NEXT:fsd ft0, 8(sp)
+; RV32F-NEXT:lw a0, 8(sp)
+; RV32F-NEXT:lw a1, 12(sp)
+; RV32F-NEXT:addi sp, sp, 16
+; RV32F-NEXT:ret
+;
+; RV64F-LABEL: constraint_f_double:
+; RV64F:   # %bb.0:
+; RV64F-NEXT:fmv.d.x ft0, a0
+; RV64F-NEXT:lui a0, %hi(gd)
+; RV64F-NEXT:fld ft1, %lo(gd)(a0)
+; RV64F-NEXT:#APP
+; RV64F-NEXT:fadd.d ft0, ft0, ft1
+; RV64F-NEXT:#NO_APP
+; RV64F-NEXT:fmv.x.d a0, ft0
+; RV64F-NEXT:ret
+  %1 = load double, double* @gd
+  %2 = tail call double asm "fadd.d $0, $1, $2", "=f,f,f"(double %a, double %1)
+  ret double %2
+}
Index: llvm/lib/Target/RISCV/RISCVISelLowering.h
===
--- llvm/lib/Target/RISCV/RISCVISelLowering.h
+++ llvm/lib/Target/RISCV/RISCVISelLowering.h
@@ -92,

[PATCH] D65500: [RISCV] Support 'f' Inline Assembly Constraint

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65500/new/

https://reviews.llvm.org/D65500



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65500: [RISCV] Support 'f' Inline Assembly Constraint

[Sam Elliott via Phabricator via cfe-commits]

lenary updated this revision to Diff 212513.
lenary added a comment.

- Simplify inline-asm-invalid.ll test


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65500/new/

https://reviews.llvm.org/D65500

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/test/CodeGen/riscv-inline-asm.c
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
  llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
  llvm/test/CodeGen/RISCV/inline-asm-invalid.ll

Index: llvm/test/CodeGen/RISCV/inline-asm-invalid.ll
===
--- llvm/test/CodeGen/RISCV/inline-asm-invalid.ll
+++ llvm/test/CodeGen/RISCV/inline-asm-invalid.ll
@@ -22,3 +22,11 @@
   tail call void asm sideeffect "csrwi mstatus, $0", "K"(i32 -1)
   ret void
 }
+
+define void @constraint_f() nounwind {
+; CHECK: error: couldn't allocate input reg for constraint 'f'
+  tail call void asm "fadd.s fa0, fa0, $0", "f"(float 0.0)
+; CHECK: error: couldn't allocate input reg for constraint 'f'
+  tail call void asm "fadd.d fa0, fa0, $0", "f"(double 0.0)
+  ret void
+}
Index: llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/inline-asm-f-constraint-f.ll
@@ -0,0 +1,34 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+f -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv64 -mattr=+f -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV64F %s
+
+@gf = external global float
+
+define float @constraint_f_float(float %a) nounwind {
+; RV32F-LABEL: constraint_f_float:
+; RV32F:   # %bb.0:
+; RV32F-NEXT:fmv.w.x ft0, a0
+; RV32F-NEXT:lui a0, %hi(gf)
+; RV32F-NEXT:flw ft1, %lo(gf)(a0)
+; RV32F-NEXT:#APP
+; RV32F-NEXT:fadd.s ft0, ft0, ft1
+; RV32F-NEXT:#NO_APP
+; RV32F-NEXT:fmv.x.w a0, ft0
+; RV32F-NEXT:ret
+;
+; RV64F-LABEL: constraint_f_float:
+; RV64F:   # %bb.0:
+; RV64F-NEXT:fmv.w.x ft0, a0
+; RV64F-NEXT:lui a0, %hi(gf)
+; RV64F-NEXT:flw ft1, %lo(gf)(a0)
+; RV64F-NEXT:#APP
+; RV64F-NEXT:fadd.s ft0, ft0, ft1
+; RV64F-NEXT:#NO_APP
+; RV64F-NEXT:fmv.x.w a0, ft0
+; RV64F-NEXT:ret
+  %1 = load float, float* @gf
+  %2 = tail call float asm "fadd.s $0, $1, $2", "=f,f,f"(float %a, float %1)
+  ret float %2
+}
Index: llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/inline-asm-d-constraint-f.ll
@@ -0,0 +1,40 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+d -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv64 -mattr=+d -verify-machineinstrs < %s \
+; RUN:   | FileCheck -check-prefix=RV64F %s
+
+@gd = external global double
+
+define double @constraint_f_double(double %a) nounwind {
+; RV32F-LABEL: constraint_f_double:
+; RV32F:   # %bb.0:
+; RV32F-NEXT:addi sp, sp, -16
+; RV32F-NEXT:sw a0, 8(sp)
+; RV32F-NEXT:sw a1, 12(sp)
+; RV32F-NEXT:fld ft0, 8(sp)
+; RV32F-NEXT:lui a0, %hi(gd)
+; RV32F-NEXT:fld ft1, %lo(gd)(a0)
+; RV32F-NEXT:#APP
+; RV32F-NEXT:fadd.d ft0, ft0, ft1
+; RV32F-NEXT:#NO_APP
+; RV32F-NEXT:fsd ft0, 8(sp)
+; RV32F-NEXT:lw a0, 8(sp)
+; RV32F-NEXT:lw a1, 12(sp)
+; RV32F-NEXT:addi sp, sp, 16
+; RV32F-NEXT:ret
+;
+; RV64F-LABEL: constraint_f_double:
+; RV64F:   # %bb.0:
+; RV64F-NEXT:fmv.d.x ft0, a0
+; RV64F-NEXT:lui a0, %hi(gd)
+; RV64F-NEXT:fld ft1, %lo(gd)(a0)
+; RV64F-NEXT:#APP
+; RV64F-NEXT:fadd.d ft0, ft0, ft1
+; RV64F-NEXT:#NO_APP
+; RV64F-NEXT:fmv.x.d a0, ft0
+; RV64F-NEXT:ret
+  %1 = load double, double* @gd
+  %2 = tail call double asm "fadd.d $0, $1, $2", "=f,f,f"(double %a, double %1)
+  ret double %2
+}
Index: llvm/lib/Target/RISCV/RISCVISelLowering.h
===
--- llvm/lib/Target/RISCV/RISCVISelLowering.h
+++ llvm/lib/Target/RISCV/RISCVISelLowering.h
@@ -92,6 +92,7 @@
   // This method returns the name of a target specific DAG node.
   const char *getTargetNodeName(unsigned Opcode) const override;
 
+  ConstraintType getConstraintType(StringRef Constraint) const override;
   std::pair
   getRegForInlineAsmConstraint(const TargetRegisterInfo *TRI,
StringRef Constraint, MVT VT) const override;
Index: llvm/lib/Target/RISCV/RISCVISelLowering.cpp
===
--- llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -2397,6 +2397,21 @@
   return nullptr;
 }
 
+/// get

[PATCH] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri requested changes to this revision.
lebedev.ri added a comment.
This revision now requires changes to proceed.

Thank you for working on this!

I'm guessing this doesn't have a `-Werror=` mode?

I still believe this should output a remark.
It will still be visible in the compiler console output,
but won't get buried there but will actually be recorded in the remarks file.




Comment at: clang/lib/CodeGen/MisExpect.cpp:1
+//===--- MisExpect.cpp - Emit LLVM Code from Statements 
---===//
+//

Wrong comment



Comment at: clang/lib/CodeGen/MisExpect.cpp:36
+  if (!Call)
+return Optional(None);
+

llvm::None



Comment at: clang/lib/CodeGen/MisExpect.cpp:40
+  if (!FD || FD->getBuiltinID() != Builtin::BI__builtin_expect) {
+return Optional(None);
+  }

`llvm::None`



Comment at: clang/lib/CodeGen/MisExpect.cpp:50
+  if (!ExprResult.Val.hasValue())
+return Optional(None);
+

llvm::None



Comment at: clang/lib/CodeGen/MisExpect.cpp:54
+  int64_t ExpectedVal = Into.getExtValue();
+  return Optional(ExpectedVal);
+}

return ExpectedVal;
should just work?



Comment at: clang/lib/CodeGen/MisExpect.cpp:140-146
+void EmitMisExpectWarning(const CallExpr *Call, CodeGenModule &CGM) {
+  SourceLocation ExprLoc = Call->getBeginLoc();
+  unsigned DiagID = CGM.getDiags().getCustomDiagID(
+  DiagnosticsEngine::Warning, "Current PGO counters disagree with "
+  "the use of __builtin_expect().");
+  CGM.getDiags().Report(ExprLoc, DiagID);
+}

This is rather undescriptive.
Can you output some more useful info?



Comment at: clang/lib/CodeGen/MisExpect.h:1
+//===--- MisExpect.h - Emit LLVM Code from Statements 
-===//
+//

Wrong comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65300/new/

https://reviews.llvm.org/D65300



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62525: [Analyzer] Add new visitor to the iterator checkers

[Balogh, Ádám via Phabricator via cfe-commits]

baloghadamsoftware marked 2 inline comments as done.
baloghadamsoftware added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:281-282
+
+  // `FoundChange` becomes true when we find the statement the results in the
+  // current state of the iterator.
+  // `FoundEmptyness` becomes true when we find the block edge assuming

Szelethus wrote:
> baloghadamsoftware wrote:
> > NoQ wrote:
> > > I don't think we should stop here. I think it's worth it to highlight 
> > > *all* increments and decrements of the interesting iterator, so that it 
> > > was clear how come that it has the given value.
> > > 
> > > Additionally, because iterators are copied around, it makes sense to 
> > > "recursively" apply the visitor to the original object when the iterator 
> > > is obtained as a copy (similarly to how `trackExpressionValue` works).
> > This can be done but an iterator can reach the past-the-end or the first 
> > position by changing the container's size as well, not only by incrementing 
> > or decrementing the iterator itself.
> Maybe in a followup patch, but I'd love to see a `trackIterator` function!
Hey, but it is done now, in the updated patch! See lines 1782-1803.



Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:1495-1496
 
   // For deque-like containers invalidate all iterator positions. For
   // vector-like containers invalidate iterator positions after the insertion.
   const auto *Cont = Pos->getContainer();

Szelethus wrote:
> >>! In D62525#1523026, @baloghadamsoftware wrote:
> > For example, an insertion happens into a vector that invalidates all the 
> > iterators at and after the position where it is inserted.
> 
> Is this actually correct?
> 
> https://en.cppreference.com/w/cpp/container/deque
> > std::deque (double-ended queue) is an indexed sequence container that 
> > allows fast insertion and deletion at both its beginning and its end. In 
> > addition, insertion and deletion at either end of a deque never invalidates 
> > pointers or references to the rest of the elements.
> 
> https://en.cppreference.com/w/cpp/container/vector
> 
> > `insert`, `emplace`, `resize`: If the vector changed capacity, all of the 
> > iterators are invalidated. If not, only those after the insertion point.
[[ https://en.cppreference.com/w/cpp/container/deque/insert | 
https://en.cppreference.com/w/cpp/container/deque/insert ]]

//All iterators, including the past-the-end iterator, are invalidated.//

I think I speak here about `insert()`, not about `push_back()` and 
`push_front()`.

Since we use a conservative approach we always assume that vectors and 
double-end queues do not change capacities.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62525/new/

https://reviews.llvm.org/D62525



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65445: [CrossTU] Handle case when no USR could be generated during Decl search.

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D65445#1607803 , @balazske wrote:

> It looks like that the problem can happen when the anonymous union is in any 
> `DeclContext` and for CTU import the import of a variable is requested and 
> that variable is in a related `DeclContext` (it can be at upper or lower 
> level). (See code of `findDefInDeclContext`: If used for variables, it goes 
> through every `DeclContext` and computes USR for specific `VarDecl`s until 
> the one is found. If we have luck it may be found before the union. An 
> anonymous union can not be imported because we get no USR for it so it is OK 
> to ignore these.) So the test can be written in many other forms but this 
> case (the code of `f`) was encountered in protobuf code.


Thanks for the explanation.

So, IIUC we cannot generate the USR for the member of the anonymous union, 
right? `f` or `i` below does not have a USR.

  class TestAnonUnionUSR {
  public:
inline float f(int value) {
  union {
float f;
int i;
  };
  i = value;
  return f;
}
static const int Test;
  };

And `findDefInDeclContext` goes through all children DC. So if the DC is 
`TestAnonUnionUSR` then we may try to get the USR for `f` and `i`. Please 
confirm if I understand it correctly or not.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65445/new/

https://reviews.llvm.org/D65445



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64753: [CrossTU][NFCI] Refactor loadExternalAST function

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/CrossTU/CrossTranslationUnit.cpp:489
+  if (DisplayCTUProgress) {
+if (llvm::Expected FileName =
+ASTStorage.getFileForFunction(LookupName, CrossTUDir, IndexName))

` LoadOperation` should not be successful if the condition here is true.
Perhaps `LoadOperation.wasSuccessful();` should be done right before the last 
return stmt in the function.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64753/new/

https://reviews.llvm.org/D64753



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63932: [GlobalDCE] Dead Virtual Function Elimination

[Oliver Stannard (Linaro) via Phabricator via cfe-commits]

ostannard added a comment.

> - Take the example from my earlier message, give the "main executable" and 
> "DSO" hidden visibility, build the "main executable" with LTO and the "DSO" 
> without LTO, and statically link them both into the same executable. We run 
> into the same problem where the Plugin1 vtable is potentially not referenced 
> and thus misoptimised. Yes, this is a violation of the LTO visibility rules, 
> but the example shows that we only detect it sometimes. I think that if we 
> did want to detect cases where the LTO visibility rules are clearly being 
> violated, the outcome should be to issue a diagnostic and not to silently 
> proceed with optimizations disabled, since the violation might be masking 
> other undetected issues. That really seems orthogonal to this patch, though.

As you say, this is a violation of the LTO visibility rules, so 
`[[clang::lto_visibility_public]]` must be used. I've gated this optimisation 
behind `-fwhole-program-vtables`, which if I've understood 
https://clang.llvm.org/docs/LTOVisibility.html correctly, is effectively the 
user asserting to the compiler that they've followed the LTO visility rules 
correctly.

> - Imagine linking part of a program with ld -r with LTO -- all symbols 
> including vtable symbols will appear to be externally visible, which is not 
> necessarily a violation of the LTO visibility rules because they may not be 
> used externally in the final link. So we end up pessimising unnecessarily.

I'm not really familiar with partial linking, is there any good documentation 
on how it is supposed to interact with LTO?

I've tried to make the changed to vcall_visibility as similar to the normal LTO 
internalisation process as possible, it happens at the same time and under the 
same conditions. If partial linking prevents normal internalisation, which will 
in turn prevent most of the existing optimisations done by GlobalDCE, then 
surely it should also prevent internalisation of vcall_visibility?

> I gave this some more thought and it seems that the frontend has all of the 
> information required to make a determination about whether to allow VFE, 
> without needing to teach LTO to relax visibility. We can make the frontend do 
> this:
> 
> - If -flto was passed (see CodeGenOptions::PrepareForLTO), attach "allow VFE" 
> metadata if class has hidden LTO visibility.
> - Otherwise, attach "allow VFE" metadata if class is not isExternallyVisible.
> 
>   Now the behaviour of GlobalDCE can be made conditional on the "allow VFE" 
> metadata alone. This also has the advantage of simplifying the IR by making 
> "allow VFE" a boolean rather than a tri-state as it is now.

The problem with that is that GlobalDCE is still run in the pre-linking 
pipeline when emiting an LTO object, because it can remove code/data which 
already has internal linkage. To make this work, we'd have to do one of:

- Tell GlobalDCE whether it is running in LTO post-linking or not, so it can 
avoid doing VFE before internalisation.   This breaks the idea that the IR 
contains all the information needed to determine if an optimisation is legal or 
not.
- Remove the pre-linking runs of GlobalDCE when doing LTO. This will result in 
more known-dead code reaching the LTO link stage, and results in a pass which 
is only valid at certain points in the pipeline.
- Split VFE out of GlobalDCE. This would result in worse optimisation, because 
chains of dependencies involving both virtual calls and regular references 
won't be followed fully.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63932/new/

https://reviews.llvm.org/D63932



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367428 - [AArch64] Add support for Transactional Memory Extension (TME)

[Momchil Velikov via cfe-commits]

Author: chill
Date: Wed Jul 31 05:52:17 2019
New Revision: 367428

URL: http://llvm.org/viewvc/llvm-project?rev=367428&view=rev
Log:
[AArch64] Add support for Transactional Memory Extension (TME)

Re-commit r366322 after some fixes

TME is a future architecture technology, documented in

  
https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools
  https://developer.arm.com/docs/ddi0601/a

More about the future architectures:

  
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture

This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and
TCANCEL and the target feature/arch extension "tme".

It also implements TME builtin functions, defined in ACLE Q2 2019
(https://developer.arm.com/docs/101028/latest)

Differential Revision: https://reviews.llvm.org/D64416

Patch by Javed Absar and Momchil Velikov

Added:
cfe/trunk/test/CodeGen/aarch64-tme.cpp
cfe/trunk/test/Sema/aarch64-tme-errors.c
cfe/trunk/test/Sema/aarch64-tme-tcancel-errors.c
Modified:
cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
cfe/trunk/lib/Basic/Targets/AArch64.cpp
cfe/trunk/lib/Basic/Targets/AArch64.h
cfe/trunk/lib/Headers/arm_acle.h
cfe/trunk/lib/Sema/SemaChecking.cpp

Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=367428&r1=367427&r2=367428&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Wed Jul 31 05:52:17 2019
@@ -91,6 +91,12 @@ LANGBUILTIN(__sevl,  "v", "",   ALL_MS_L
 // Misc
 BUILTIN(__builtin_sponentry, "v*", "c")
 
+// Transactional Memory Extension
+BUILTIN(__builtin_arm_tstart, "WUi", "nj")
+BUILTIN(__builtin_arm_tcommit, "v", "n")
+BUILTIN(__builtin_arm_tcancel, "vWUIi", "n")
+BUILTIN(__builtin_arm_ttest, "WUi", "nc")
+
 TARGET_HEADER_BUILTIN(_BitScanForward, "UcUNi*UNi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_BitScanReverse, "UcUNi*UNi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_BitScanForward64, "UcUNi*ULLi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")

Modified: cfe/trunk/lib/Basic/Targets/AArch64.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AArch64.cpp?rev=367428&r1=367427&r2=367428&view=diff
==
--- cfe/trunk/lib/Basic/Targets/AArch64.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/AArch64.cpp Wed Jul 31 05:52:17 2019
@@ -216,6 +216,9 @@ void AArch64TargetInfo::getTargetDefines
   if (HasMTE)
 Builder.defineMacro("__ARM_FEATURE_MEMORY_TAGGING", "1");
 
+  if (HasTME)
+Builder.defineMacro("__ARM_FEATURE_TME", "1");
+
   if ((FPU & NeonMode) && HasFP16FML)
 Builder.defineMacro("__ARM_FEATURE_FP16FML", "1");
 
@@ -267,6 +270,7 @@ bool AArch64TargetInfo::handleTargetFeat
   HasDotProd = false;
   HasFP16FML = false;
   HasMTE = false;
+  HasTME = false;
   ArchKind = llvm::AArch64::ArchKind::ARMV8A;
 
   for (const auto &Feature : Features) {
@@ -298,6 +302,8 @@ bool AArch64TargetInfo::handleTargetFeat
   HasFP16FML = true;
 if (Feature == "+mte")
   HasMTE = true;
+if (Feature == "+tme")
+  HasTME = true;
   }
 
   setDataLayout();

Modified: cfe/trunk/lib/Basic/Targets/AArch64.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AArch64.h?rev=367428&r1=367427&r2=367428&view=diff
==
--- cfe/trunk/lib/Basic/Targets/AArch64.h (original)
+++ cfe/trunk/lib/Basic/Targets/AArch64.h Wed Jul 31 05:52:17 2019
@@ -35,6 +35,7 @@ class LLVM_LIBRARY_VISIBILITY AArch64Tar
   bool HasDotProd;
   bool HasFP16FML;
   bool HasMTE;
+  bool HasTME;
 
   llvm::AArch64::ArchKind ArchKind;
 

Modified: cfe/trunk/lib/Headers/arm_acle.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/arm_acle.h?rev=367428&r1=367427&r2=367428&view=diff
==
--- cfe/trunk/lib/Headers/arm_acle.h (original)
+++ cfe/trunk/lib/Headers/arm_acle.h Wed Jul 31 05:52:17 2019
@@ -613,7 +613,7 @@ __jcvt(double __a) {
 #define __arm_wsr64(sysreg, v) __builtin_arm_wsr64(sysreg, v)
 #define __arm_wsrp(sysreg, v) __builtin_arm_wsrp(sysreg, v)
 
-// Memory Tagging Extensions (MTE) Intrinsics
+/* Memory Tagging Extensions (MTE) Intrinsics */
 #if __ARM_FEATURE_MEMORY_TAGGING
 #define __arm_mte_create_random_tag(__ptr, __mask)  __builtin_arm_irg(__ptr, 
__mask)
 #define __arm_mte_increment_tag(__ptr, __tag_offset)  
__builtin_arm_addg(__ptr, __tag_offset)
@@ -623,6 +623,28 @@ __jcvt(double __a) {
 #define __arm_mte_ptrdiff(__ptra, __ptrb) __builtin_arm_subp(__ptra, __ptrb)
 #endif
 
+/* Transactional M

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

[Momchil Velikov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367428: [AArch64] Add support for Transactional Memory 
Extension (TME) (authored by chill, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D64416?vs=212332&id=212559#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64416/new/

https://reviews.llvm.org/D64416

Files:
  cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
  cfe/trunk/lib/Basic/Targets/AArch64.cpp
  cfe/trunk/lib/Basic/Targets/AArch64.h
  cfe/trunk/lib/Headers/arm_acle.h
  cfe/trunk/lib/Sema/SemaChecking.cpp
  cfe/trunk/test/CodeGen/aarch64-tme.cpp
  cfe/trunk/test/Sema/aarch64-tme-errors.c
  cfe/trunk/test/Sema/aarch64-tme-tcancel-errors.c
  llvm/trunk/include/llvm/IR/IntrinsicsAArch64.td
  llvm/trunk/include/llvm/Support/AArch64TargetParser.def
  llvm/trunk/include/llvm/Support/AArch64TargetParser.h
  llvm/trunk/lib/Target/AArch64/AArch64.td
  llvm/trunk/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/trunk/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/trunk/lib/Target/AArch64/AArch64Subtarget.h
  llvm/trunk/test/CodeGen/AArch64/tme.ll
  llvm/trunk/test/MC/AArch64/tme-error.s
  llvm/trunk/test/MC/AArch64/tme.s
  llvm/trunk/test/MC/Disassembler/AArch64/tme.txt
  llvm/trunk/unittests/Support/TargetParserTest.cpp

Index: llvm/trunk/include/llvm/Support/AArch64TargetParser.def
===
--- llvm/trunk/include/llvm/Support/AArch64TargetParser.def
+++ llvm/trunk/include/llvm/Support/AArch64TargetParser.def
@@ -79,6 +79,7 @@
 AARCH64_ARCH_EXT_NAME("ssbs", AArch64::AEK_SSBS,"+ssbs",  "-ssbs")
 AARCH64_ARCH_EXT_NAME("sb",   AArch64::AEK_SB,  "+sb","-sb")
 AARCH64_ARCH_EXT_NAME("predres",  AArch64::AEK_PREDRES, "+predres", "-predres")
+AARCH64_ARCH_EXT_NAME("tme",  AArch64::AEK_TME, "+tme",   "-tme")
 #undef AARCH64_ARCH_EXT_NAME
 
 #ifndef AARCH64_CPU_NAME
Index: llvm/trunk/include/llvm/Support/AArch64TargetParser.h
===
--- llvm/trunk/include/llvm/Support/AArch64TargetParser.h
+++ llvm/trunk/include/llvm/Support/AArch64TargetParser.h
@@ -54,6 +54,7 @@
   AEK_SVE2SM4 = 1 << 25,
   AEK_SVE2SHA3 =1 << 26,
   AEK_SVE2BITPERM = 1 << 27,
+  AEK_TME = 1 << 28,
 };
 
 enum class ArchKind {
Index: llvm/trunk/include/llvm/IR/IntrinsicsAArch64.td
===
--- llvm/trunk/include/llvm/IR/IntrinsicsAArch64.td
+++ llvm/trunk/include/llvm/IR/IntrinsicsAArch64.td
@@ -733,3 +733,18 @@
 def int_aarch64_stgp  : Intrinsic<[], [llvm_ptr_ty, llvm_i64_ty, llvm_i64_ty],
 [IntrWriteMem, IntrArgMemOnly, NoCapture<0>, WriteOnly<0>]>;
 }
+
+// Transactional Memory Extension (TME) Intrinsics
+let TargetPrefix = "aarch64" in {
+def int_aarch64_tstart  : GCCBuiltin<"__builtin_arm_tstart">,
+ Intrinsic<[llvm_i64_ty]>;
+
+def int_aarch64_tcommit : GCCBuiltin<"__builtin_arm_tcommit">, Intrinsic<[]>;
+
+def int_aarch64_tcancel : GCCBuiltin<"__builtin_arm_tcancel">,
+  Intrinsic<[], [llvm_i64_ty], [ImmArg<0>]>;
+
+def int_aarch64_ttest   : GCCBuiltin<"__builtin_arm_ttest">,
+  Intrinsic<[llvm_i64_ty], [],
+[IntrNoMem, IntrHasSideEffects]>;
+}
Index: llvm/trunk/test/CodeGen/AArch64/tme.ll
===
--- llvm/trunk/test/CodeGen/AArch64/tme.ll
+++ llvm/trunk/test/CodeGen/AArch64/tme.ll
@@ -0,0 +1,44 @@
+; RUN: llc %s -verify-machineinstrs -o - | FileCheck %s
+
+target triple = "aarch64-unknown-unknown-eabi"
+
+define i64 @test_tstart() #0 {
+  %r = tail call i64 @llvm.aarch64.tstart()
+  ret i64 %r
+}
+declare i64 @llvm.aarch64.tstart() #1
+; CHECK-LABEL: test_tstart
+; CHECK: tstart x
+
+define i64 @test_ttest() #0 {
+  %r = tail call i64 @llvm.aarch64.ttest()
+  ret i64 %r
+}
+declare i64 @llvm.aarch64.ttest() #1
+; CHECK-LABEL: test_ttest
+; CHECK: ttest x
+
+define void @test_tcommit() #0 {
+  tail call void @llvm.aarch64.tcommit()
+  ret void
+}
+declare void @llvm.aarch64.tcommit() #1
+; CHECK-LABEL: test_tcommit
+; CHECK: tcommit
+
+define void @test_tcancel() #0 {
+  tail call void @llvm.aarch64.tcancel(i64 0) #1
+  tail call void @llvm.aarch64.tcancel(i64 1) #1
+  tail call void @llvm.aarch64.tcancel(i64 65534) #1
+  tail call void @llvm.aarch64.tcancel(i64 65535) #1
+  ret void
+}
+declare void @llvm.aarch64.tcancel(i64 immarg) #1
+; CHECK-LABEL: test_tcancel
+; CHECK: tcancel #0
+; CHECK: tcancel #0x1
+; CHECK: tcancel #0xfffe
+; CHECK: tcancel #0x
+
+attributes #0 = { "target-features"="+tme" }
+attributes #1 = { nounwind }
Index: llvm/trunk/test/MC/AArch64/tme-error.s
===
--- llvm/trunk/test/MC/AArch64/tme-error.s
+++ llvm/trunk/test/MC/AArch64/tme

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

Thanks for the comments, LGTM!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65486/new/

https://reviews.llvm.org/D65486



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65445: [CrossTU] Handle case when no USR could be generated during Decl search.

[Balázs Kéri via Phabricator via cfe-commits]

balazske added a comment.

Probably this is a problem case too but only if the `f` or `i` has an 
initializer expression and really no USR is generated for `f` or `i`. But what 
I have found is that there is a `VarDecl` for a "invisible" variable whose type 
is the anonymous union and it has a (default) initializer too. If the search 
reaches DC of the `f` it will try to get the USR for this variable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65445/new/

https://reviews.llvm.org/D65445



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 212567.
serge-sans-paille added a comment.

Make validation more resilient depending on shared/static build.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61446/new/

https://reviews.llvm.org/D61446

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CMakeLists.txt
  clang/tools/driver/CMakeLists.txt
  clang/tools/driver/cc1_main.cpp
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/docs/WritingAnLLVMPass.rst
  llvm/examples/Bye/Bye.cpp
  llvm/examples/Bye/CMakeLists.txt
  llvm/examples/CMakeLists.txt
  llvm/include/llvm/Config/llvm-config.h.cmake
  llvm/test/Feature/load_extension.ll
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/opt-O0-pipeline.ll
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/test/lit.cfg.py
  llvm/test/lit.site.cfg.py.in
  llvm/tools/CMakeLists.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/opt/CMakeLists.txt
  llvm/tools/opt/NewPMDriver.cpp
  llvm/tools/opt/opt.cpp
  llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
  polly/include/polly/RegisterPasses.h
  polly/lib/CMakeLists.txt
  polly/lib/Polly.cpp
  polly/lib/Support/RegisterPasses.cpp
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in
  polly/test/update_check.py

Index: polly/test/update_check.py
===
--- polly/test/update_check.py
+++ polly/test/update_check.py
@@ -15,7 +15,7 @@
 polly_lib_dir = '''@POLLY_LIB_DIR@'''
 shlibext = '''@LLVM_SHLIBEXT@'''
 llvm_tools_dir = '''@LLVM_TOOLS_DIR@'''
-link_polly_into_tools = not '''@LINK_POLLY_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','link_polly_into_tools-notfound'}
+llvm_polly_link_into_tools = not '''@LLVM_POLLY_LINK_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','llvm_polly_link_into_tools-notfound'}
 
 runre = re.compile(r'\s*\;\s*RUN\s*\:(?P.*)')
 filecheckre = re.compile(r'\s*(?P.*)\|\s*(?PFileCheck\s[^|]*)')
@@ -298,7 +298,7 @@
 toolarg = toolarg.replace('%s', filename)
 toolarg = toolarg.replace('%S', os.path.dirname(filename))
 if toolarg == '%loadPolly':
-if not link_polly_into_tools:
+if not llvm_polly_link_into_tools:
 newtool += ['-load',os.path.join(polly_lib_dir,'LLVMPolly' + shlibext)]
 newtool.append('-polly-process-unprofitable')
 newtool.append('-polly-remarks-minimal')
Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -8,7 +8,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
 config.extra_paths = "@POLLY_TEST_EXTRA_PATHS@".split(";")
 
@@ -36,14 +36,14 @@
 # directories.
 config.excludes = ['Inputs']
 
-if config.link_polly_into_tools == '' or \
-   config.link_polly_into_tools.lower() == '0' or \
-   config.link_polly_into_tools.lower() == 'n' or \
-   config.link_polly_into_tools.lower() == 'no' or \
-   config.link_polly_into_tools.lower() == 'off' or \
-   config.link_polly_into_tools.lower() == 'false' or \
-   config.link_polly_into_tools.lower() == 'notfound' or \
-   config.link_polly_into_tools.lower() == 'link_polly_into_tools-notfound':
+if config.llvm_polly_link_into_tools == '' or \
+   config.llvm_polly_link_into_tools.lower() == '0' or \
+   config.llvm_polly_link_into_tools.lower() == 'n' or \
+   config.llvm_polly_link_into_tools.lower() == 'no' or \
+   config.llvm_polly_link_into_tools.lower() == 'off' or \
+   config.llvm_polly_link_into_tools.lower() == 'false' or \
+   config.llvm_polly_link_into_tools.lower() == 'notfound' or \
+   config.llvm_polly_link_into_tools.lower() == 'llvm_polly_link_into_tools-notfound':
 config.substitutions.append(('%loadPolly', '-load '
  + config.polly_lib_dir + '/LLVMPolly@LLVM_SHLIBEXT@'
  + ' -load-pass-plugin '
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -13,7 +13,7 @@
 config.shlibdir = "@SHLIBDIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.has_unittests = @POLLY_GTEST_AVAIL@
 
 # Support substitution of the tools_dir, libs_dirs, and build_mode with user
Index: polly/

[PATCH] D65510: [clangd] Fix implicit template instatiations appearing as topLevelDecls.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom created this revision.
jvikstrom added reviewers: hokein, ilya-biryukov.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

The parser gives implicit template instantiations to the action's 
HandleTopLevelDecls callback. This makes semantic highlighting highlight these 
templated functions multiple times. Fixed by filtering on if a Decl is an 
implicit function/variable/class instantiation. Also added a testcase to 
semantic highlighting on this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65510

Files:
  clang-tools-extra/clangd/ClangdUnit.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -214,7 +214,25 @@
 
   template
   void $Function[[foo]]($TemplateParameter[[T]] ...);
-)cpp"};
+)cpp",
+R"cpp(
+  class $Class[[Foo]] {
+  public:
+template 
+void $Method[[ff]]($TemplateParameter[[T1]]) {}
+  };
+  template 
+  void $Function[[ff]]($TemplateParameter[[T1]]) {}
+  enum $Enum[[E]] { $EnumConstant[[VALUE]] };
+  void $Function[[s]]() {
+$Function[[ff]]($EnumConstant[[VALUE]]);
+$Function[[ff]]($Class[[Foo]]());
+$Class[[Foo]] $Variable[[s]];
+$Variable[[s]].$Method[[ff]]($EnumConstant[[VALUE]]);
+$Variable[[s]].$Method[[ff]]($Class[[Foo]]());
+  }
+)cpp"
+  };
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
   }
Index: clang-tools-extra/clangd/ClangdUnit.cpp
===
--- clang-tools-extra/clangd/ClangdUnit.cpp
+++ clang-tools-extra/clangd/ClangdUnit.cpp
@@ -19,8 +19,11 @@
 #include "index/CanonicalIncludes.h"
 #include "index/Index.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
@@ -60,6 +63,12 @@
   return Vec.capacity() * sizeof(T);
 }
 
+template  bool isImplicitTemplateInstantiation(const Decl *D) {
+  if (const auto *TD = dyn_cast(D))
+return TD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation;
+  return false;
+}
+
 class DeclTrackingASTConsumer : public ASTConsumer {
 public:
   DeclTrackingASTConsumer(std::vector &TopLevelDecls)
@@ -70,6 +79,10 @@
   auto &SM = D->getASTContext().getSourceManager();
   if (!isInsideMainFile(D->getLocation(), SM))
 continue;
+  if (isImplicitTemplateInstantiation(D) ||
+  isImplicitTemplateInstantiation(D) ||
+  isImplicitTemplateInstantiation(D))
+continue;
 
   // ObjCMethodDecl are not actually top-level decls.
   if (isa(D))


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -214,7 +214,25 @@
 
   template
   void $Function[[foo]]($TemplateParameter[[T]] ...);
-)cpp"};
+)cpp",
+R"cpp(
+  class $Class[[Foo]] {
+  public:
+template 
+void $Method[[ff]]($TemplateParameter[[T1]]) {}
+  };
+  template 
+  void $Function[[ff]]($TemplateParameter[[T1]]) {}
+  enum $Enum[[E]] { $EnumConstant[[VALUE]] };
+  void $Function[[s]]() {
+$Function[[ff]]($EnumConstant[[VALUE]]);
+$Function[[ff]]($Class[[Foo]]());
+$Class[[Foo]] $Variable[[s]];
+$Variable[[s]].$Method[[ff]]($EnumConstant[[VALUE]]);
+$Variable[[s]].$Method[[ff]]($Class[[Foo]]());
+  }
+)cpp"
+  };
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
   }
Index: clang-tools-extra/clangd/ClangdUnit.cpp
===
--- clang-tools-extra/clangd/ClangdUnit.cpp
+++ clang-tools-extra/clangd/ClangdUnit.cpp
@@ -19,8 +19,11 @@
 #include "index/CanonicalIncludes.h"
 #include "index/Index.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
@@ -60,6 +63,12 @@
   return Vec.capacity() * sizeof(T);
 }
 
+template  bool isImplicitTemplateInstantiation(const Decl *D) {
+  if (con

[PATCH] D65511: Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006)

[Hans Wennborg via Phabricator via cfe-commits]

hans created this revision.
hans added reviewers: rnk, rsmith.

This is similar to r245139, but that only addressed dllexported classes. It was 
still possible to run into the same problem with dllexported members in an 
otherwise normal class (see bug). This uses the same strategy to fix: delay 
defining the method until the whole class has been parsed.

(The easiest way to see the ordering problem is in 
Parser::ParseCXXMemberSpecification(): it calls ParseLexedMemberInitializers() 
*after* ActOnFinishCXXMemberDecls(), which was trying to define the dllexport 
method. Now we delay it to ActOnFinishCXXNonNestedClass() which is called after 
both of those.)


https://reviews.llvm.org/D65511

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CodeGenCXX/dllexport.cpp


Index: clang/test/CodeGenCXX/dllexport.cpp
===
--- clang/test/CodeGenCXX/dllexport.cpp
+++ clang/test/CodeGenCXX/dllexport.cpp
@@ -851,6 +851,15 @@
 // Baz's operator=, causing instantiation of Foo after which
 // ActOnFinishCXXNonNestedClass is called, and we would bite our own tail.
 // M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
dereferenceable(1) %"struct.InClassInits::Baz"* 
@"??4Baz@InClassInits@@QAEAAU01@ABU01@@Z"
+
+// Trying to define the explicitly defaulted ctor must be delayed until the
+// in-class initializer for x has been processed.
+struct PR40006 {
+  __declspec(dllexport) PR40006() = default;
+  int x = 42;
+};
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.InClassInits::PR40006"* @"??0PR40006@InClassInits@@QAE@XZ"
+
 }
 
 // We had an issue where instantiating A would force emission of B's delayed
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -6283,8 +6283,8 @@
 M->dropAttr();
 
   if (M->hasAttr()) {
-DefineImplicitSpecialMember(*this, M, M->getLocation());
-ActOnFinishInlineFunctionDef(M);
+// Define after any fields with in-class initializers have been parsed.
+DelayedDllExportMemberFunctions.push_back(M);
   }
 }
   };
@@ -11537,6 +11537,15 @@
 
 void Sema::ActOnFinishCXXNonNestedClass(Decl *D) {
   referenceDLLExportedClassMethods();
+
+  if (!DelayedDllExportMemberFunctions.empty()) {
+SmallVector WorkList;
+std::swap(DelayedDllExportMemberFunctions, WorkList);
+for (CXXMethodDecl *M : WorkList) {
+  DefineImplicitSpecialMember(*this, M, M->getLocation());
+  ActOnFinishInlineFunctionDef(M);
+}
+  }
 }
 
 void Sema::referenceDLLExportedClassMethods() {
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -961,6 +961,7 @@
 
   // All dllexport classes should have been processed already.
   assert(DelayedDllExportClasses.empty());
+  assert(DelayedDllExportMemberFunctions.empty());
 
   // Remove file scoped decls that turned out to be used.
   UnusedFileScopedDecls.erase(
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -11136,6 +11136,7 @@
   // Emitting members of dllexported classes is delayed until the class
   // (including field initializers) is fully parsed.
   SmallVector DelayedDllExportClasses;
+  SmallVector DelayedDllExportMemberFunctions;
 
 private:
   class SavePendingParsedClassStateRAII {


Index: clang/test/CodeGenCXX/dllexport.cpp
===
--- clang/test/CodeGenCXX/dllexport.cpp
+++ clang/test/CodeGenCXX/dllexport.cpp
@@ -851,6 +851,15 @@
 // Baz's operator=, causing instantiation of Foo after which
 // ActOnFinishCXXNonNestedClass is called, and we would bite our own tail.
 // M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc dereferenceable(1) %"struct.InClassInits::Baz"* @"??4Baz@InClassInits@@QAEAAU01@ABU01@@Z"
+
+// Trying to define the explicitly defaulted ctor must be delayed until the
+// in-class initializer for x has been processed.
+struct PR40006 {
+  __declspec(dllexport) PR40006() = default;
+  int x = 42;
+};
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc %"struct.InClassInits::PR40006"* @"??0PR40006@InClassInits@@QAE@XZ"
+
 }
 
 // We had an issue where instantiating A would force emission of B's delayed
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -6283,8 +6283,8 @@
 M->dropAttr();
 
   if (M->hasAttr()) {
-DefineImplicitSpecialMember(*this, M, M->getLocation());
-ActOnFinishInlineFunctionDef(M);
+// Define after any fields wi

r367431 - AMDGPU: Add missing builtin declarations

[Matt Arsenault via cfe-commits]

Author: arsenm
Date: Wed Jul 31 07:03:05 2019
New Revision: 367431

URL: http://llvm.org/viewvc/llvm-project?rev=367431&view=rev
Log:
AMDGPU: Add missing builtin declarations

Modified:
cfe/trunk/include/clang/Basic/BuiltinsAMDGPU.def
cfe/trunk/test/CodeGenOpenCL/builtins-amdgcn.cl

Modified: cfe/trunk/include/clang/Basic/BuiltinsAMDGPU.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAMDGPU.def?rev=367431&r1=367430&r2=367431&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsAMDGPU.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsAMDGPU.def Wed Jul 31 07:03:05 2019
@@ -118,6 +118,13 @@ BUILTIN(__builtin_amdgcn_cvt_pknorm_u16,
 BUILTIN(__builtin_amdgcn_cvt_pk_i16, "E2sii", "nc")
 BUILTIN(__builtin_amdgcn_cvt_pk_u16, "E2UsUiUi", "nc")
 BUILTIN(__builtin_amdgcn_cvt_pk_u8_f32, "UifUiUi", "nc")
+BUILTIN(__builtin_amdgcn_sad_u8, "UiUiUiUi", "nc")
+BUILTIN(__builtin_amdgcn_msad_u8, "UiUiUiUi", "nc")
+BUILTIN(__builtin_amdgcn_sad_hi_u8, "UiUiUiUi", "nc")
+BUILTIN(__builtin_amdgcn_sad_u16, "UiUiUiUi", "nc")
+BUILTIN(__builtin_amdgcn_qsad_pk_u16_u8, "LUiLUiUiLUi", "nc")
+BUILTIN(__builtin_amdgcn_mqsad_pk_u16_u8, "LUiLUiUiLUi", "nc")
+BUILTIN(__builtin_amdgcn_mqsad_u32_u8, "V4UiLUiUiV4Ui", "nc")
 
 
//===--===//
 // CI+ only builtins.

Modified: cfe/trunk/test/CodeGenOpenCL/builtins-amdgcn.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/builtins-amdgcn.cl?rev=367431&r1=367430&r2=367431&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/builtins-amdgcn.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/builtins-amdgcn.cl Wed Jul 31 07:03:05 2019
@@ -9,6 +9,7 @@ typedef unsigned short ushort;
 typedef half __attribute__((ext_vector_type(2))) half2;
 typedef short __attribute__((ext_vector_type(2))) short2;
 typedef ushort __attribute__((ext_vector_type(2))) ushort2;
+typedef uint __attribute__((ext_vector_type(4))) uint4;
 
 // CHECK-LABEL: @test_div_scale_f64
 // CHECK: call { double, i1 } @llvm.amdgcn.div.scale.f64(double %a, double %b, 
i1 true)
@@ -654,6 +655,48 @@ kernel void test_cvt_pk_u8_f32(global ui
   *out = __builtin_amdgcn_cvt_pk_u8_f32(src0, src1, src2);
 }
 
+// CHECK-LABEL: @test_sad_u8(
+// CHECK: tail call i32 @llvm.amdgcn.sad.u8(i32 %src0, i32 %src1, i32 %src2)
+kernel void test_sad_u8(global uint* out, uint src0, uint src1, uint src2) {
+  *out = __builtin_amdgcn_sad_u8(src0, src1, src2);
+}
+
+// CHECK-LABEL: test_msad_u8(
+// CHECK: call i32 @llvm.amdgcn.msad.u8(i32 %src0, i32 %src1, i32 %src2)
+kernel void test_msad_u8(global uint* out, uint src0, uint src1, uint src2) {
+  *out = __builtin_amdgcn_msad_u8(src0, src1, src2);
+}
+
+// CHECK-LABEL: test_sad_hi_u8(
+// CHECK: call i32 @llvm.amdgcn.sad.hi.u8(i32 %src0, i32 %src1, i32 %src2)
+kernel void test_sad_hi_u8(global uint* out, uint src0, uint src1, uint src2) {
+  *out = __builtin_amdgcn_sad_hi_u8(src0, src1, src2);
+}
+
+// CHECK-LABEL: @test_sad_u16(
+// CHECK: call i32 @llvm.amdgcn.sad.u16(i32 %src0, i32 %src1, i32 %src2)
+kernel void test_sad_u16(global uint* out, uint src0, uint src1, uint src2) {
+  *out = __builtin_amdgcn_sad_u16(src0, src1, src2);
+}
+
+// CHECK-LABEL: @test_qsad_pk_u16_u8(
+// CHECK: call i64 @llvm.amdgcn.qsad.pk.u16.u8(i64 %src0, i32 %src1, i64 %src2)
+kernel void test_qsad_pk_u16_u8(global ulong* out, ulong src0, uint src1, 
ulong src2) {
+  *out = __builtin_amdgcn_qsad_pk_u16_u8(src0, src1, src2);
+}
+
+// CHECK-LABEL: @test_mqsad_pk_u16_u8(
+// CHECK: call i64 @llvm.amdgcn.mqsad.pk.u16.u8(i64 %src0, i32 %src1, i64 
%src2)
+kernel void test_mqsad_pk_u16_u8(global ulong* out, ulong src0, uint src1, 
ulong src2) {
+  *out = __builtin_amdgcn_mqsad_pk_u16_u8(src0, src1, src2);
+}
+
+// CHECK-LABEL: test_mqsad_u32_u8(
+// CHECK: call <4 x i32> @llvm.amdgcn.mqsad.u32.u8(i64 %src0, i32 %src1, <4 x 
i32> %src2)
+kernel void test_mqsad_u32_u8(global uint4* out, ulong src0, uint src1, uint4 
src2) {
+  *out = __builtin_amdgcn_mqsad_u32_u8(src0, src1, src2);
+}
+
 // CHECK-DAG: [[$WI_RANGE]] = !{i32 0, i32 1024}
 // CHECK-DAG: attributes #[[$NOUNWIND_READONLY:[0-9]+]] = { nounwind readonly }
 // CHECK-DAG: attributes #[[$READ_EXEC_ATTRS]] = { convergent }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65454: AMDGPU: Add missing builtin declarations

[Matt Arsenault via Phabricator via cfe-commits]

arsenm closed this revision.
arsenm added a comment.

r367431


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65454/new/

https://reviews.llvm.org/D65454



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Shaurya Gupta via Phabricator via cfe-commits]

SureYeaah added inline comments.



Comment at: clang-tools-extra/clangd/Selection.cpp:50
+  S.StartOffset = SM.getFileOffset(Tok.location());
+  S.EndOffset = S.StartOffset + Tok.length();
+  if (S.StartOffset >= SelBegin && S.EndOffset <= SelEnd)

Would this work correctly for nested templates? Or do we need to use the 
specialized token length function that we use for toHalfOpenFileRange?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65486/new/

https://reviews.llvm.org/D65486



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65517: [Preprocessor] Always discard body of #define if we failed to parse it

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov created this revision.
ilya-biryukov added a reviewer: sammccall.
Herald added a project: clang.

Preivously we would only discard it if we failed to parse parameter lists.
If we do not consume the body, parser sees tokens inside directive. In
turns, this leads to spurious diagnostics and crash in TokenBuffer, see
the added tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65517

Files:
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/stringize_skipped.c
  clang/unittests/Tooling/Syntax/TokensTest.cpp


Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -298,6 +298,21 @@
   spelled tokens:
 
   no mappings.
+)"},
+  // Should not crash on errors inside '#define' directives. Error is that
+  // stringification (#B) does not refer to a macro parameter.
+  {
+  R"cpp(
+a
+#define MACRO() A #B
+)cpp",
+  R"(expanded tokens:
+  a
+file './input.cpp'
+  spelled tokens:
+a # define MACRO ( ) A # B
+  mappings:
+['#'_1, ''_9) => [''_1, ''_1)
 )"}};
   for (auto &Test : TestCases)
 EXPECT_EQ(collectAndDump(Test.first), Test.second)
Index: clang/test/Preprocessor/stringize_skipped.c
===
--- /dev/null
+++ clang/test/Preprocessor/stringize_skipped.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// Ensure we see the error from PP and do not see errors from the parser.
+
+// expected-error@+1{{'#' is not followed by a macro parameter}}
+#define INVALID() #B 10+10
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -33,6 +33,7 @@
 #include "clang/Lex/Token.h"
 #include "clang/Lex/VariadicMacroSupport.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/STLExtras.h"
@@ -2399,6 +2400,13 @@
   Token Tok;
   LexUnexpandedToken(Tok);
 
+  // Ensure we consume the rest of the macro body if errors occur.
+  auto _ = llvm::make_scope_exit([&]() {
+// The flag indicates if we have already reached 'eod'.
+if (CurLexer->ParsingPreprocessorDirective)
+  DiscardUntilEndOfDirective();
+  });
+
   // Used to un-poison and then re-poison identifiers of the __VA_ARGS__ ilk
   // within their appropriate context.
   VariadicMacroScopeGuard VariadicMacroScopeGuard(*this);
@@ -2420,12 +2428,8 @@
   } else if (Tok.is(tok::l_paren)) {
 // This is a function-like macro definition.  Read the argument list.
 MI->setIsFunctionLike();
-if (ReadMacroParameterList(MI, LastTok)) {
-  // Throw away the rest of the line.
-  if (CurPPLexer->ParsingPreprocessorDirective)
-DiscardUntilEndOfDirective();
+if (ReadMacroParameterList(MI, LastTok))
   return nullptr;
-}
 
 // If this is a definition of an ISO C/C++ variadic function-like macro 
(not
 // using the GNU named varargs extension) inform our variadic scope guard


Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -298,6 +298,21 @@
   spelled tokens:
 
   no mappings.
+)"},
+  // Should not crash on errors inside '#define' directives. Error is that
+  // stringification (#B) does not refer to a macro parameter.
+  {
+  R"cpp(
+a
+#define MACRO() A #B
+)cpp",
+  R"(expanded tokens:
+  a
+file './input.cpp'
+  spelled tokens:
+a # define MACRO ( ) A # B
+  mappings:
+['#'_1, ''_9) => [''_1, ''_1)
 )"}};
   for (auto &Test : TestCases)
 EXPECT_EQ(collectAndDump(Test.first), Test.second)
Index: clang/test/Preprocessor/stringize_skipped.c
===
--- /dev/null
+++ clang/test/Preprocessor/stringize_skipped.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// Ensure we see the error from PP and do not see errors from the parser.
+
+// expected-error@+1{{'#' is not followed by a macro parameter}}
+#define INVALID() #B 10+10
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -33,6 +33,7 @@
 #include "clang/Lex/Token.h"
 #include "clang/Lex/VariadicMacroSupport.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/STLExtras.h"
@@ -2399,6 +2400,13 @@
   Token Tok;
   LexUnexpandedToken(Tok);
 
+  // Ensure we consume the rest of the macro body if errors occur.
+  auto _ = 

[PATCH] D65382: [analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it const

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D65382#1605769 , 
@baloghadamsoftware wrote:

> Most managers are stateful because they also store the elements they manage 
> (e.g. `ProgramStateManager` stores states, `SValBuilder` owns other managers 
> such as `SymbolManager` that stores symbols etc.)


That's an implementation detail, a memoization, a good use case for `mutable` 
if we go for const-correctness. For example, no observable properties of 
`SymbolManager` change when it allocates a new symbol. The interface only 
allows you to ask "What's the symbol for a //value-that-transcends-time// with 
a certain identity?" and it retrieves you that symbol. There's no way to find 
out if the symbol is freshly created or already cached, and there shouldn't be 
a way to find this out, because this is entirely immaterial and meaningless.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65382/new/

https://reviews.llvm.org/D65382



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65387: [clangd] Add a callback mechanism for handling responses from client.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 212586.
hokein marked 11 inline comments as done.
hokein added a comment.

address comments:

- move the reply callback handling code to MessageHandler;
- prevent memory leakage when LSP clients don't send back the reply;
- use the new machanism for applyTweak and apply fix;
- update all relevant tests;


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65387/new/

https://reviews.llvm.org/D65387

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/code-action-request.test
  clang-tools-extra/clangd/test/execute-command.test
  clang-tools-extra/clangd/test/fixits-command.test
  clang-tools-extra/clangd/test/tweaks-format.test

Index: clang-tools-extra/clangd/test/tweaks-format.test
===
--- clang-tools-extra/clangd/test/tweaks-format.test
+++ clang-tools-extra/clangd/test/tweaks-format.test
@@ -6,6 +6,7 @@
 {"jsonrpc":"2.0","id":5,"method":"textDocument/codeAction","params":{"textDocument":{"uri":"test:///main.cc"},"range":{"start":{"line":0,"character":11},"end":{"line":0,"character":11}},"context":{"diagnostics":[]}}}
 ---
 {"jsonrpc":"2.0","id":6,"method":"workspace/executeCommand","params":{"command":"clangd.applyTweak","arguments":[{"file":"test:///main.cc","selection":{"end":{"character":11,"line":0},"start":{"character":11,"line":0}},"tweakID":"SwapIfBranches"}]}}
+#  CHECK:"id": 0,
 #  CHECK:"newText": "\n  ",
 # CHECK-NEXT:"range": {
 # CHECK-NEXT:  "end": {
@@ -45,6 +46,8 @@
 # CHECK-NEXT:}
 # CHECK-NEXT:  }
 ---
+{"jsonrpc":"2.0","id":0,"result":{"applied":true}}
+---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---
 {"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/test/fixits-command.test
===
--- clang-tools-extra/clangd/test/fixits-command.test
+++ clang-tools-extra/clangd/test/fixits-command.test
@@ -165,10 +165,6 @@
 # CHECK-NEXT:  ]
 ---
 {"jsonrpc":"2.0","id":4,"method":"workspace/executeCommand","params":{"command":"clangd.applyFix","arguments":[{"changes":{"test:///foo.c":[{"range":{"start":{"line":0,"character":32},"end":{"line":0,"character":32}},"newText":"("},{"range":{"start":{"line":0,"character":37},"end":{"line":0,"character":37}},"newText":")"}]}}]}}
-#  CHECK:  "id": 4,
-# CHECK-NEXT:  "jsonrpc": "2.0",
-# CHECK-NEXT:  "result": "Fix applied."
-#
 #  CHECK:  "id": 0,
 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:  "method": "workspace/applyEdit",
@@ -207,6 +203,11 @@
 # CHECK-NEXT:}
 # CHECK-NEXT:  }
 ---
+{"jsonrpc":"2.0","id":0,"result":{"applied":true}}
+#  CHECK:  "id": 4,
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": "Fix applied."
+---
 {"jsonrpc":"2.0","id":4,"method":"shutdown"}
 ---
 {"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/test/execute-command.test
===
--- clang-tools-extra/clangd/test/execute-command.test
+++ clang-tools-extra/clangd/test/execute-command.test
@@ -33,6 +33,8 @@
 ---
 {"jsonrpc":"2.0","id":5,"method":"workspace/executeCommand","params":{"command":"clangd.applyFix","custom":"foo", "arguments":[{"changes":{"test:///foo.c":[{"range":{"start":{"line":0,"character":32},"end":{"line":0,"character":32}},"newText":"("},{"range":{"start":{"line":0,"character":37},"end":{"line":0,"character":37}},"newText":")"}]}}]}}
 ---
+{"jsonrpc":"2.0","id":0,"result":{"applied":false}}
+---
 # Arguments not a sequence.
 {"jsonrpc":"2.0","id":6,"method":"workspace/executeCommand","params":{"command":"clangd.applyFix","arguments":"foo"}}
 ---
@@ -45,6 +47,8 @@
 # Custom field in WorkspaceEdit
 {"jsonrpc":"2.0","id":9,"method":"workspace/executeCommand","params":{"command":"clangd.applyFix","arguments":[{"custom":"foo", "changes":{"test:///foo.c":[{"range":{"start":{"line":0,"character":32},"end":{"line":0,"character":32}},"newText":"("},{"range":{"start":{"line":0,"character":37},"end":{"line":0,"character":37}},"newText":")"}]}}]}}
 ---
+{"jsonrpc":"2.0","id":1,"result":{"applied":false}}
+---
 # changes in WorkspaceEdit with no mapping node
 {"jsonrpc":"2.0","id":10,"method":"workspace/executeCommand","params":{"command":"clangd.applyFix","arguments":[{"changes":"foo"}]}}
 ---
@@ -61,8 +65,10 @@
 {"jsonrpc":"2.0","id":14,"method":"workspace/executeCommand","params":{"command":"clangd.applyFix","arguments":[{"changes":{"test:///foo.c":[{"range":{"start":{"line":0,"character":32},"end":{"line":0,"character":32}},"newText":"("},{"range":"","newText":")"}]}}]}}
 ---
 # Command name after arguments
-{"jsonrpc":"2.0","id":9,"method":"workspace/executeCommand","params":{"arguments":[{"custom":"foo", "changes":{"test:///foo.c":[{"range":{"start":{"line":0,"ch

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom marked an inline comment as done.
jvikstrom added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1125
+Old = std::move(FileToHighlightings[File]);
+FileToHighlightings[File] = Highlightings;
+  }

hokein wrote:
> ilya-biryukov wrote:
> > NIT: avoid copying (from `Highlightings` into the map) under a lock, make 
> > the copy outside the lock instead
> I think we can even avoid copy, since we only use the `Highlightings` for 
> calculating the diff.
> 
> Maybe just 
> 
> ```
> {
> std::lock_guard Lock(HighlightingsMutex);
> Old = std::move(FileToHighlightings[File]);
> }
> // calculate the diff.
> {  
>  std::lock_guard Lock(HighlightingsMutex);
>  FileToHighlightings[File] = std::move(Highlightings);
> }
> ```
I think I changed this to only lock once (and copy instead) at the same time me 
and @ilya-biryukov were talking about the race condition (?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

[Anton Afanasyev via Phabricator via cfe-commits]

anton-afanasyev added a comment.

Ping!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63325/new/

https://reviews.llvm.org/D63325



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64907: [AST] Traverse attributes inside DEF_TRAVERSE_DECL macro

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov updated this revision to Diff 212591.
ilya-biryukov added a comment.
Herald added a subscriber: mgorny.

- Add a test


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64907/new/

https://reviews.llvm.org/D64907

Files:
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/unittests/AST/CMakeLists.txt
  clang/unittests/AST/RecursiveASTVisitorTest.cpp

Index: clang/unittests/AST/RecursiveASTVisitorTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/RecursiveASTVisitorTest.cpp
@@ -0,0 +1,105 @@
+//===- unittest/AST/RecursiveASTVisitorTest.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/ASTConsumer.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Attr.h"
+#include "clang/Frontend/FrontendAction.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/FunctionExtras.h"
+#include "llvm/ADT/STLExtras.h"
+#include "gmock/gmock-generated-matchers.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+using ::testing::ElementsAre;
+
+namespace {
+class ProcessASTAction : public clang::ASTFrontendAction {
+public:
+  ProcessASTAction(llvm::unique_function Process)
+  : Process(std::move(Process)) {
+assert(this->Process);
+  }
+
+  std::unique_ptr CreateASTConsumer(CompilerInstance &CI,
+ StringRef InFile) {
+class Consumer : public ASTConsumer {
+public:
+  Consumer(llvm::function_ref Process)
+  : Process(Process) {}
+
+  void HandleTranslationUnit(ASTContext &Ctx) override { Process(Ctx); }
+
+private:
+  llvm::function_ref Process;
+};
+
+return llvm::make_unique(Process);
+  }
+
+private:
+  llvm::unique_function Process;
+};
+
+enum class VisitEvent {
+  StartTraverseFunction,
+  EndTraverseFunction,
+  StartTraverseAttr,
+  EndTraverseAttr
+};
+
+class CollectInterestingEvents
+: public RecursiveASTVisitor {
+public:
+  bool TraverseFunctionDecl(FunctionDecl *D) {
+Events.push_back(VisitEvent::StartTraverseFunction);
+bool Ret = RecursiveASTVisitor::TraverseFunctionDecl(D);
+Events.push_back(VisitEvent::EndTraverseFunction);
+
+return Ret;
+  }
+
+  bool TraverseAttr(Attr *A) {
+Events.push_back(VisitEvent::StartTraverseAttr);
+bool Ret = RecursiveASTVisitor::TraverseAttr(A);
+Events.push_back(VisitEvent::EndTraverseAttr);
+
+return Ret;
+  }
+
+  std::vector takeEvents() && { return std::move(Events); }
+
+private:
+  std::vector Events;
+};
+
+std::vector collectEvents(llvm::StringRef Code) {
+  CollectInterestingEvents Visitor;
+  clang::tooling::runToolOnCode(
+  new ProcessASTAction(
+  [&](clang::ASTContext &Ctx) { Visitor.TraverseAST(Ctx); }),
+  Code);
+  return std::move(Visitor).takeEvents();
+}
+} // namespace
+
+TEST(RecursiveASTVisitorTest, AttributesInsideDecls) {
+  /// Check attributes are traversed inside TraverseFunctionDecl.
+  llvm::StringRef Code = R"cpp(
+__attribute__((annotate("something"))) int foo() { return 10; }
+  )cpp";
+
+  EXPECT_THAT(collectEvents(Code), ElementsAre(VisitEvent::StartTraverseFunction,
+   VisitEvent::StartTraverseAttr,
+   VisitEvent::EndTraverseAttr,
+   VisitEvent::EndTraverseFunction));
+}
\ No newline at end of file
Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -26,6 +26,7 @@
   Language.cpp
   NamedDeclPrinterTest.cpp
   OMPStructuredBlockTest.cpp
+  RecursiveASTVisitorTest.cpp
   SourceLocationTest.cpp
   StmtPrinterTest.cpp
   StructuralEquivalenceTest.cpp
Index: clang/include/clang/AST/RecursiveASTVisitor.h
===
--- clang/include/clang/AST/RecursiveASTVisitor.h
+++ clang/include/clang/AST/RecursiveASTVisitor.h
@@ -722,12 +722,6 @@
 break;
 #include "clang/AST/DeclNodes.inc"
   }
-
-  // Visit any attributes attached to this declaration.
-  for (auto *I : D->attrs()) {
-if (!getDerived().TraverseAttr(I))
-  return false;
-  }
   return true;
 }
 
@@ -1407,6 +1401,11 @@
 { CODE; }  \
 if (ReturnValue && ShouldVisitChildren)\
   TRY_TO(TraverseDeclContextHelper(dyn_cast(D))); \
+if (ReturnValue) {  

[PATCH] D64907: [AST] Traverse attributes inside DEF_TRAVERSE_DECL macro

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov updated this revision to Diff 212592.
ilya-biryukov added a comment.

- Reformat


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64907/new/

https://reviews.llvm.org/D64907

Files:
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/unittests/AST/CMakeLists.txt
  clang/unittests/AST/RecursiveASTVisitorTest.cpp

Index: clang/unittests/AST/RecursiveASTVisitorTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/RecursiveASTVisitorTest.cpp
@@ -0,0 +1,106 @@
+//===- unittest/AST/RecursiveASTVisitorTest.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/ASTConsumer.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Attr.h"
+#include "clang/Frontend/FrontendAction.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/FunctionExtras.h"
+#include "llvm/ADT/STLExtras.h"
+#include "gmock/gmock-generated-matchers.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+using ::testing::ElementsAre;
+
+namespace {
+class ProcessASTAction : public clang::ASTFrontendAction {
+public:
+  ProcessASTAction(llvm::unique_function Process)
+  : Process(std::move(Process)) {
+assert(this->Process);
+  }
+
+  std::unique_ptr CreateASTConsumer(CompilerInstance &CI,
+ StringRef InFile) {
+class Consumer : public ASTConsumer {
+public:
+  Consumer(llvm::function_ref Process)
+  : Process(Process) {}
+
+  void HandleTranslationUnit(ASTContext &Ctx) override { Process(Ctx); }
+
+private:
+  llvm::function_ref Process;
+};
+
+return llvm::make_unique(Process);
+  }
+
+private:
+  llvm::unique_function Process;
+};
+
+enum class VisitEvent {
+  StartTraverseFunction,
+  EndTraverseFunction,
+  StartTraverseAttr,
+  EndTraverseAttr
+};
+
+class CollectInterestingEvents
+: public RecursiveASTVisitor {
+public:
+  bool TraverseFunctionDecl(FunctionDecl *D) {
+Events.push_back(VisitEvent::StartTraverseFunction);
+bool Ret = RecursiveASTVisitor::TraverseFunctionDecl(D);
+Events.push_back(VisitEvent::EndTraverseFunction);
+
+return Ret;
+  }
+
+  bool TraverseAttr(Attr *A) {
+Events.push_back(VisitEvent::StartTraverseAttr);
+bool Ret = RecursiveASTVisitor::TraverseAttr(A);
+Events.push_back(VisitEvent::EndTraverseAttr);
+
+return Ret;
+  }
+
+  std::vector takeEvents() && { return std::move(Events); }
+
+private:
+  std::vector Events;
+};
+
+std::vector collectEvents(llvm::StringRef Code) {
+  CollectInterestingEvents Visitor;
+  clang::tooling::runToolOnCode(
+  new ProcessASTAction(
+  [&](clang::ASTContext &Ctx) { Visitor.TraverseAST(Ctx); }),
+  Code);
+  return std::move(Visitor).takeEvents();
+}
+} // namespace
+
+TEST(RecursiveASTVisitorTest, AttributesInsideDecls) {
+  /// Check attributes are traversed inside TraverseFunctionDecl.
+  llvm::StringRef Code = R"cpp(
+__attribute__((annotate("something"))) int foo() { return 10; }
+  )cpp";
+
+  EXPECT_THAT(collectEvents(Code),
+  ElementsAre(VisitEvent::StartTraverseFunction,
+  VisitEvent::StartTraverseAttr,
+  VisitEvent::EndTraverseAttr,
+  VisitEvent::EndTraverseFunction));
+}
\ No newline at end of file
Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -26,6 +26,7 @@
   Language.cpp
   NamedDeclPrinterTest.cpp
   OMPStructuredBlockTest.cpp
+  RecursiveASTVisitorTest.cpp
   SourceLocationTest.cpp
   StmtPrinterTest.cpp
   StructuralEquivalenceTest.cpp
Index: clang/include/clang/AST/RecursiveASTVisitor.h
===
--- clang/include/clang/AST/RecursiveASTVisitor.h
+++ clang/include/clang/AST/RecursiveASTVisitor.h
@@ -722,12 +722,6 @@
 break;
 #include "clang/AST/DeclNodes.inc"
   }
-
-  // Visit any attributes attached to this declaration.
-  for (auto *I : D->attrs()) {
-if (!getDerived().TraverseAttr(I))
-  return false;
-  }
   return true;
 }
 
@@ -1407,6 +1401,11 @@
 { CODE; }  \
 if (ReturnValue && ShouldVisitChildren)\
   TRY_TO(TraverseDeclContextHelper(dyn_cast(D))); \
+if (ReturnValue) { \
+  /* Visit any attributes attached to this declarat

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: test/Sema/warn-int-in-bool-context.c:26
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+

jfb wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > xbolva00 wrote:
> > > > jfb wrote:
> > > > > I'm not sure the "did you mean" part is helpful. Do we have data 
> > > > > showing that this is what people actually mean?
> > > > No, no data, just what GCC suggests.
> > > I would drop it without knowing that it's actually what people usually 
> > > mean.
> > Leave just “<<' in boolean context“ seems not ideal for me as a diag 
> > message. 
> > 
> > Or is it ok for you?
> As [I said above](https://reviews.llvm.org/D63082#inline-585063), I don't 
> think you should say "boolean context". It's not something people will 
> understand. Here we're assigning to a boolean, say that.
> As I said above, I don't think you should say "boolean context". It's not 
> something people will understand. Here we're assigning to a boolean, say that.

Strong +1.

As for the "did you mean", I actually see that as somewhat reasonable text. 
`<<` is a reasonable typo for `<` (which yields a bool), similar for `>>` and 
`>`. However, if we had data to back up that presumption, it would be better.



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

xbolva00 wrote:
> jfb wrote:
> > xbolva00 wrote:
> > > jfb wrote:
> > > > xbolva00 wrote:
> > > > > xbolva00 wrote:
> > > > > > @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of 
> > > > > > logical '||' with constant operand' here..
> > > > > > 
> > > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > > > >  warning: use of logical '||' with constant operand
> > > > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > > > boolean context}}
> > > > > >  ^  ~~
> > > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > > > >  note: use '|' for a bitwise operation
> > > > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > > > boolean context}}
> > > > > >  ^~
> > > > > >  |
> > > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
> > > > > >  warning: enum constant in boolean context
> > > > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > > > boolean context}}
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > What is your opinion here (^^) , @jfb ?
> > > > > 
> > > > > Thanks.
> > > > C, C++, ObjC, and ObjC++ should emit different diagnostics here. That 
> > > > being said, none of these diagnostics are particular easy to 
> > > > understand. I don't think we should ever say "boolean context" anywhere.
> > > So I will make this as it was - C++ only.
> > It'll work in the other languages though, right?
> Sight, making it C++ only leaves C with not diagnosed case:
> 
> _Bool f() { return orange; }
> 
> And I don’t know why ‘use of logical || with constant operand’ is C only :/..
> And I don’t know why ‘use of logical || with constant operand’ is C only :/..

It may be worth doing the svn blame dance to see if it's discussed as part of 
the original review. One possibility is that `||` can be overloaded in C++ and 
so perhaps || with a constant operand is not a bug. But that seems like pretty 
weak rationale (we can always see if there's an overloaded || and not issue the 
diagnostic in that circumstance).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64475: [clangd] Duplicate lines of semantic highlightings sent removed.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov accepted this revision.
ilya-biryukov marked an inline comment as done.
ilya-biryukov added a comment.

LGTM from my side




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1125
+Old = std::move(FileToHighlightings[File]);
+FileToHighlightings[File] = Highlightings;
+  }

jvikstrom wrote:
> hokein wrote:
> > ilya-biryukov wrote:
> > > NIT: avoid copying (from `Highlightings` into the map) under a lock, make 
> > > the copy outside the lock instead
> > I think we can even avoid copy, since we only use the `Highlightings` for 
> > calculating the diff.
> > 
> > Maybe just 
> > 
> > ```
> > {
> > std::lock_guard Lock(HighlightingsMutex);
> > Old = std::move(FileToHighlightings[File]);
> > }
> > // calculate the diff.
> > {  
> >  std::lock_guard Lock(HighlightingsMutex);
> >  FileToHighlightings[File] = std::move(Highlightings);
> > }
> > ```
> I think I changed this to only lock once (and copy instead) at the same time 
> me and @ilya-biryukov were talking about the race condition (?)
It means there's a window where nobody can access the highlightings for this 
file. Which is probably fine, we really do use this only for computing the diff 
and nothing else.

But doing the copy shouldn't matter here either, so leaving as is also looks ok 
from my side.

If you decide to avoid an extra copy, please add comments to 
`FileToHighlightings` (e.g. `only used to compute diffs, must not be used 
outside onHighlightingsReady and didRemove`).
It is declared really close to `FixItsMap` and looks very similar, but the 
latter is used in completely different ways; that could lead to confusion.

Don't remember exact details about race conditions, but we should be good now 
that it's called inside `Publish()`



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:408
+}
+
 } // namespace

jvikstrom wrote:
> ilya-biryukov wrote:
> > ilya-biryukov wrote:
> > > Could you also add a separate test that checks diffs when the number of 
> > > lines is getting smaller (i.e. taking `NLines` into account)
> > I would expect this to be better handled outside `checkDiffedHighlights` to 
> > avoid over-generalizing this function. But up to you.
> That's what this test does: 
> 
> ```
> {
> R"(
> $Class[[A]]
> $Variable[[A]]
> $Class[[A]]
> $Variable[[A]]
>   )",
> R"(
> $Class[[A]]
> $Variable[[A]]
>   )"},
> ```
> 
> But do you mean I should do a testcase like:
> 
> 
> 
> ```
> {
> R"(
> $Class[[A]]
> $Variable[[A]]
> $Class[[A]]
> $Variable[[A]]
>   )",
> R"(
> $Class[[A]]
> $Variable[[A]]
> $Class[[A]]
> $Variable[[A]]
>   )"},
> ```
> And just set NLines = 2 instead when doing the diffing?
> 
Ah, the test actually needs the set of changed lines to be **exactly** the same 
as marked lines.
In that case, all is good, I've just missed this detail.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64475/new/

https://reviews.llvm.org/D64475



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

aaron.ballman wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > xbolva00 wrote:
> > > > jfb wrote:
> > > > > xbolva00 wrote:
> > > > > > xbolva00 wrote:
> > > > > > > @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of 
> > > > > > > logical '||' with constant operand' here..
> > > > > > > 
> > > > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > > > > >  warning: use of logical '||' with constant operand
> > > > > > >   if (f == apple || orange) // expected-warning {{enum constant 
> > > > > > > in boolean context}}
> > > > > > >  ^  ~~
> > > > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > > > > >  note: use '|' for a bitwise operation
> > > > > > >   if (f == apple || orange) // expected-warning {{enum constant 
> > > > > > > in boolean context}}
> > > > > > >  ^~
> > > > > > >  |
> > > > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
> > > > > > >  warning: enum constant in boolean context
> > > > > > >   if (f == apple || orange) // expected-warning {{enum constant 
> > > > > > > in boolean context}}
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > What is your opinion here (^^) , @jfb ?
> > > > > > 
> > > > > > Thanks.
> > > > > C, C++, ObjC, and ObjC++ should emit different diagnostics here. That 
> > > > > being said, none of these diagnostics are particular easy to 
> > > > > understand. I don't think we should ever say "boolean context" 
> > > > > anywhere.
> > > > So I will make this as it was - C++ only.
> > > It'll work in the other languages though, right?
> > Sight, making it C++ only leaves C with not diagnosed case:
> > 
> > _Bool f() { return orange; }
> > 
> > And I don’t know why ‘use of logical || with constant operand’ is C only 
> > :/..
> > And I don’t know why ‘use of logical || with constant operand’ is C only 
> > :/..
> 
> It may be worth doing the svn blame dance to see if it's discussed as part of 
> the original review. One possibility is that `||` can be overloaded in C++ 
> and so perhaps || with a constant operand is not a bug. But that seems like 
> pretty weak rationale (we can always see if there's an overloaded || and not 
> issue the diagnostic in that circumstance).
But even if we fix ‘use of logical .. with constants” for C++, we the break 
this patch (clang will produce two similar warnings) and if we remove it from 
this patch, some cases stay undiagnosed:

bool foo() return orange;

In order to support this case, we cant use this place to implement the check.

Not good..


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added a comment.

Did you resolve the conflicting `llvmGetPassPluginInfo` symbols for windows?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61446/new/

https://reviews.llvm.org/D61446



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

C FE:

-IfStmt 0x55a225bc4dc8 

  | |-BinaryOperator 0x55a225bc4d48  'int' '||'
  | | |-BinaryOperator 0x55a225bc4d08  'int' '=='
  | | | |-ImplicitCastExpr 0x55a225bc4cf0  'int' 
  | | | | `-ImplicitCastExpr 0x55a225bc4cd8  'enum fruit':'enum fruit' 

  | | | |   `-DeclRefExpr 0x55a225bc4c98  'enum fruit':'enum fruit' 
lvalue ParmVar 0x55a225bc4a90 'f' 'enum fruit':'enum fruit'
  | | | `-DeclRefExpr 0x55a225bc4cb8  'int' EnumConstant 0x55a225bc4610 
'apple' 'int'
  | | `-DeclRefExpr 0x55a225bc4d28  'int' EnumConstant 0x55a225bc4520 
'orange' 'int'

C++ FE:
IfStmt 0x55cfd2ae5d20 

  | |-BinaryOperator 0x55cfd2ae5ca0  'bool' '||'
  | | |-BinaryOperator 0x55cfd2ab9940  'bool' '=='
  | | | |-ImplicitCastExpr 0x55cfd2ab9910  'int' 
  | | | | `-ImplicitCastExpr 0x55cfd2ab98f8  'enum fruit':'fruit' 

  | | | |   `-DeclRefExpr 0x55cfd2ab98b8  'enum fruit':'fruit' lvalue 
ParmVar 0x55cfd2ab96b0 'f' 'enum fruit':'fruit'
  | | | `-ImplicitCastExpr 0x55cfd2ab9928  'int' 
  | | |   `-DeclRefExpr 0x55cfd2ab98d8  'fruit' EnumConstant 
0x55cfd2ab8ef8 'apple' 'fruit'
  | | `-ImplicitCastExpr 0x55cfd2ab9980  'bool' 
  | |   `-DeclRefExpr 0x55cfd2ab9960  'fruit' EnumConstant 
0x55cfd2ab8e08 'orange' 'fruit'

https://github.com/llvm-mirror/clang/blob/9b127f3b44e685cbe513595b7e0115b0884b0604/lib/Sema/SemaExpr.cpp#L6701


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367447 - [InstCombine] canonicalize fneg before fmul/fdiv

[Sanjay Patel via cfe-commits]

Author: spatel
Date: Wed Jul 31 09:53:22 2019
New Revision: 367447

URL: http://llvm.org/viewvc/llvm-project?rev=367447&view=rev
Log:
[InstCombine] canonicalize fneg before fmul/fdiv

Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it
easier to implement the transforms (and possibly other fneg transforms) in
1 place because we can always start the pattern match from fneg (either the
legacy binop or the new unop).

There's a secondary practical benefit seen in PR21914 and PR42681:
https://bugs.llvm.org/show_bug.cgi?id=21914
https://bugs.llvm.org/show_bug.cgi?id=42681
...hoisting fneg rather than sinking seems to play nicer with LICM in IR
(although this change may expose analysis holes in the other direction).

1. The instcombine test changes show the expected neutral IR diffs from
   reversing the order.

2. The reassociation tests show that we were missing an optimization
   opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says
   that all of these transforms are allowed (regardless of binop/unop
   fneg version) because:

   "For all other operations [besides copy/abs/negate/copysign], this
   standard does not specify the sign bit of a NaN result."
   In all of these transforms, we always have some other binop
   (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a
   potential intermediate NaN operand.
   (If that interpretation is wrong, then we must already have a bug in
   the existing transforms?)

3. The clang tests shouldn't exist as-is, but that's effectively a
   revert of rL367149 (the test broke with an extension of the
   pre-existing fneg canonicalization in rL367146).

Differential Revision: https://reviews.llvm.org/D65399

Modified:
cfe/trunk/test/CodeGen/complex-math.c

Modified: cfe/trunk/test/CodeGen/complex-math.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/complex-math.c?rev=367447&r1=367446&r2=367447&view=diff
==
--- cfe/trunk/test/CodeGen/complex-math.c (original)
+++ cfe/trunk/test/CodeGen/complex-math.c Wed Jul 31 09:53:22 2019
@@ -148,10 +148,11 @@ float _Complex div_float_rc(float a, flo
   // AARCH64-FASTMATH: [[CCpDD:%.*]] = fadd fast float [[CC]], [[DD]]
   //
   // BC = 0
-  // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast float [[D]], %a
-  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fdiv fast float [[AC]], [[CCpDD]]
-  // AARCH64-FASTMATH: [[DIV:%.*]] = fdiv fast float [[AD]], [[CCpDD]]
-  // AARCH64-FASTMATH: fsub fast float -0.00e+00, [[DIV]]
+  // AARCH64-FASTMATH: [[NEGA:%.*]] = fsub fast float -0.00e+00, %a
+  // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast float  [[D]], [[NEGA]]
+  //
+  // AARCH64-FASTMATH: fdiv fast float [[AC]], [[CCpDD]]
+  // AARCH64-FASTMATH: fdiv fast float [[AD]], [[CCpDD]]
   // AARCH64-FASTMATH: ret
   return a / b;
 }
@@ -325,10 +326,11 @@ double _Complex div_double_rc(double a,
   // AARCH64-FASTMATH: [[CCpDD:%.*]] = fadd fast double [[CC]], [[DD]]
   //
   // BC = 0
-  // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast double [[D]], %a
-  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fdiv fast double [[AC]], [[CCpDD]]
-  // AARCH64-FASTMATH: [[DIV:%.*]] = fdiv fast double [[AD]], [[CCpDD]]
-  // AARCH64-FASTMATH: fsub fast double -0.00e+00, [[DIV]]
+  // AARCH64-FASTMATH: [[NEGA:%.*]] = fsub fast double -0.00e+00, %a
+  // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast double [[D]], [[NEGA]]
+  //
+  // AARCH64-FASTMATH: fdiv fast double [[AC]], [[CCpDD]]
+  // AARCH64-FASTMATH: fdiv fast double [[AD]], [[CCpDD]]
   // AARCH64-FASTMATH: ret
   return a / b;
 }
@@ -520,10 +522,11 @@ long double _Complex div_long_double_rc(
   // AARCH64-FASTMATH: [[CCpDD:%.*]] = fadd fast fp128 [[CC]], [[DD]]
   //
   // BC = 0
-  // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast fp128 [[D]], %a
-  // AARCH64-FASTMATH: [[BCmAD:%.*]] = fdiv fast fp128 [[AC]], [[CCpDD]]
-  // AARCH64-FASTMATH: [[DIV:%.*]] = fdiv fast fp128 [[AD]], [[CCpDD]]
-  // AARCH64-FASTMATH: fsub fast fp128 0xL8000, 
[[DIV]]
+  // AARCH64-FASTMATH: [[NEGA:%.*]] = fsub fast fp128 
0xL8000, %a
+  // AARCH64-FASTMATH: [[AD:%.*]] = fmul fast fp128 [[D]], [[NEGA]]
+  //
+  // AARCH64-FASTMATH: fdiv fast fp128 [[AC]], [[CCpDD]]
+  // AARCH64-FASTMATH: fdiv fast fp128 [[AD]], [[CCpDD]]
   // AARCH64-FASTMATH: ret
   return a / b;
 }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65510: [clangd] Fix implicit template instatiations appearing as topLevelDecls.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/ClangdUnit.cpp:68
+  if (const auto *TD = dyn_cast(D))
+return TD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation;
+  return false;

We also want to skip `TSK_ExplicitInstantiationDeclaration` and  
`TSK_ExplicitInstantiationDefinition` here.
This covers cases like (not sure which one of the two enum values we get, 
though):
```
template 
int foo(T) { ... }

template int foo(int); // we'd rather not traverse these, highlightings will 
run into the same problems.
```

Semantics I'm describing are roughly similar to `isImplicitInstatiation(D) == 
!isExplicitInstantion(D)`, where `isExplicitInstantiation` is taken from 
`CodeComplete.cpp`. (If we ignore `TSK_Undeclared`, which, I believe, should 
never be encountered in decls passed to HandleTopLevelDecl).

Please extract the helper from code complete and this one into a separate file 
(e.g. `clangd/AST.h`) and possibly implement one through the other


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65510/new/

https://reviews.llvm.org/D65510



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65511: Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006)

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:11545
+for (CXXMethodDecl *M : WorkList) {
+  DefineImplicitSpecialMember(*this, M, M->getLocation());
+  ActOnFinishInlineFunctionDef(M);

Do we need to do this until fixpoint? Suppose a dllexported implicit special 
member triggers a template instantiation, and the template has a dllexported 
defaulted special member, something like:
```
struct Bar { Bar(); };
template  struct Foo { __declspec(dllexport) Foo() = default; Bar 
obj; };
struct Baz {
   ... not sure how to trigger instantiation
};
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65511/new/

https://reviews.llvm.org/D65511



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65511: Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006)

[Hans Wennborg via Phabricator via cfe-commits]

hans marked an inline comment as done.
hans added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:11545
+for (CXXMethodDecl *M : WorkList) {
+  DefineImplicitSpecialMember(*this, M, M->getLocation());
+  ActOnFinishInlineFunctionDef(M);

rnk wrote:
> Do we need to do this until fixpoint? Suppose a dllexported implicit special 
> member triggers a template instantiation, and the template has a dllexported 
> defaulted special member, something like:
> ```
> struct Bar { Bar(); };
> template  struct Foo { __declspec(dllexport) Foo() = default; Bar 
> obj; };
> struct Baz {
>... not sure how to trigger instantiation
> };
> ```
I think that should work, and that's why the function is written to be 
re-entrant by having a local worklist. If it triggers a template instantiation, 
ActOnFinishCXXNonNestedClass should get called for the newly instantiated 
class. But I'm also not sure how to write a test case that would trigger it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65511/new/

https://reviews.llvm.org/D65511



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

@Meinersbur nop, forgot that one, I'll have a look, thanks for pointing that 
out.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61446/new/

https://reviews.llvm.org/D61446



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65050: [SemaTemplate] Mark a function type as dependent when its parameter list contains pack expansion

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

I think this is reasonable, but I'd like @rsmith to weigh in -- this looks like 
it could be a Core Issue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65050/new/

https://reviews.llvm.org/D65050



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65525: [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: ilya-biryukov.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
mgorny.
Herald added a project: clang.

TweakTests.cpp has some pretty good helpers added for the first few
tweaks, but they have some limitations:

- many assertion failures point at the wrong line
- need lots of input/output tests, setup code is duplicated across both
- local helpers make it hard to split the file as it grows

The new helpers in TweakTests.h are based on old ones (same operations)
but try to address these issues and generally make tests more terse
while improving error messages.

This patch converts everything except ExtractVariable (which is complex
and has changes in flight, so will be converted later).
It's LOC-neutral, despite not being able to get rid of the old helpers
until ExtractVariable is done.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65525

Files:
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/TweakTesting.cpp
  clang-tools-extra/clangd/unittests/TweakTesting.h
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -9,6 +9,7 @@
 #include "Annotations.h"
 #include "SourceCode.h"
 #include "TestTU.h"
+#include "TweakTesting.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/Expr.h"
 #include "clang/Basic/LLVM.h"
@@ -24,11 +25,16 @@
 
 using llvm::Failed;
 using llvm::Succeeded;
+using ::testing::AllOf;
+using ::testing::HasSubstr;
+using ::testing::StartsWith;
 
 namespace clang {
 namespace clangd {
 namespace {
 
+// TODO(sammccall): migrate the rest of the tests to use TweakTesting.h and
+// remove these helpers.
 std::string markRange(llvm::StringRef Code, Range R) {
   size_t Begin = llvm::cantFail(positionToOffset(Code, R.start));
   size_t End = llvm::cantFail(positionToOffset(Code, R.end));
@@ -114,13 +120,6 @@
   return applyAllReplacements(Code.code(), *Effect->ApplyEdit);
 }
 
-std::string getMessage(StringRef ID, llvm::StringRef Input) {
-  auto Effect = apply(ID, Input);
-  if (!Effect)
-return "error: " + llvm::toString(Effect.takeError());
-  return Effect->ShowMessage.getValueOr("no message produced!");
-}
-
 void checkTransform(llvm::StringRef ID, llvm::StringRef Input,
 std::string Output) {
   auto Result = applyEdit(ID, Input);
@@ -128,148 +127,72 @@
   EXPECT_EQ(Output, std::string(*Result)) << Input;
 }
 
-/// Check if apply returns an error and that the @ErrorMessage is contained
-/// in that error
-void checkApplyContainsError(llvm::StringRef ID, llvm::StringRef Input,
- const std::string& ErrorMessage) {
-  auto Result = apply(ID, Input);
-  ASSERT_FALSE(Result) << "expected error message:\n   " << ErrorMessage <<
-   "\non input:" << Input;
-  EXPECT_THAT(llvm::toString(Result.takeError()),
-  testing::HasSubstr(ErrorMessage))
-  << Input;
-}
-
-TEST(TweakTest, SwapIfBranches) {
-  llvm::StringLiteral ID = "SwapIfBranches";
-
-  checkAvailable(ID, R"cpp(
-void test() {
-  ^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }
-}
-  )cpp");
-
-  checkNotAvailable(ID, R"cpp(
-void test() {
-  if (true) {^return ^100;^ } else { ^continue^;^ }
-}
-  )cpp");
-
-  llvm::StringLiteral Input = R"cpp(
-void test() {
-  ^if (true) { return 100; } else { continue; }
-}
-  )cpp";
-  llvm::StringLiteral Output = R"cpp(
-void test() {
-  if (true) { continue; } else { return 100; }
-}
-  )cpp";
-  checkTransform(ID, Input, Output);
-
-  Input = R"cpp(
-void test() {
-  ^if () { return 100; } else { continue; }
-}
-  )cpp";
-  Output = R"cpp(
-void test() {
-  if () { continue; } else { return 100; }
-}
-  )cpp";
-  checkTransform(ID, Input, Output);
-
-  // Available in subexpressions of the condition.
-  checkAvailable(ID, R"cpp(
-void test() {
-  if(2 + [[2]] + 2) { return 2 + 2 + 2; } else { continue; }
-}
-  )cpp");
+TWEAK_TEST(SwapIfBranches);
+TEST_F(SwapIfBranchesTest, Test) {
+  Context = Function;
+  EXPECT_EQ(apply("^if (true) {return 100;} else {continue;}"),
+"if (true) {continue;} else {return 100;}");
+  EXPECT_EQ(apply("^if () {return 100;} else {continue;}"),
+"if () {continue;} else {return 100;}") << "broken condition";
+  EXPECT_AVAILABLE("^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }");
+  EXPECT_UNAVAILABLE("if (true) {^return ^100;^ } else { ^continue^;^ }");
+  // Available in subexpressions of the condition;
+  EXPECT_THAT("if(2 + [[2]] + 2) { return 2 + 2 + 2; } else {continue;}",
+  isAvailable());
   // But not as part of the branches.
-  checkNotAvailable(ID, R"cpp(
-   

[PATCH] D65517: [Preprocessor] Always discard body of #define if we failed to parse it

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

LG, though I'm obviously not an expert here. Thanks for tracking this down!




Comment at: clang/lib/Lex/PPDirectives.cpp:2405
+  auto _ = llvm::make_scope_exit([&]() {
+// The flag indicates if we have already reached 'eod'.
+if (CurLexer->ParsingPreprocessorDirective)

nit: "if we are still waiting for eod"? (to avoid inverting the sense)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65517/new/

https://reviews.llvm.org/D65517



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

[Shaurya Gupta via Phabricator via cfe-commits]

SureYeaah created this revision.
SureYeaah added reviewers: kadircet, sammccall.
Herald added subscribers: cfe-commits, arphaman, jkorous, MaskRay, 
ilya-biryukov, mgorny.
Herald added a project: clang.

- Prototype version; Only looking for a high level review.
- Only works for extraction from free functions
- Basic analysis of the code being extracted.
- Extracts to a void function with no parameters.
- Doesn't handle semicolons yet.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65526

Files:
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp

Index: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
@@ -0,0 +1,285 @@
+//===--- ExtractFunction.cpp *- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+#include "ClangdUnit.h"
+#include "Logger.h"
+#include "Selection.h"
+#include "SourceCode.h"
+#include "refactor/Tweak.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Stmt.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "llvm/ADT/None.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/iterator_range.h"
+#include "llvm/Support/Casting.h"
+#include "llvm/Support/Error.h"
+
+namespace clang {
+namespace clangd {
+namespace {
+
+using Node = SelectionTree::Node;
+using std::shared_ptr;
+
+class ExtractionTarget {
+public:
+  ExtractionTarget(const Node *N, const SourceManager &SM,
+   const ASTContext &Ctx);
+
+  // Check if the location is part of the TargetContext and before Target.
+  bool isInPreTarget(SourceLocation Loc) const {
+return !isOutsideTargetContext(Loc) && Loc < TargetRng.getBegin();
+  }
+
+  // Checks whether the Location is within the Target.
+  bool isInTarget(SourceLocation Loc) const {
+return SM.isPointWithin(Loc, TargetRng.getBegin(), TargetRng.getEnd());
+  }
+
+  // Check if the location is part of the TargetContext and after Target.
+  bool isInPostTarget(SourceLocation Loc) const {
+return !isOutsideTargetContext(Loc) && TargetRng.getEnd() < Loc;
+  }
+  // Check if the location is outside the TargetContext.
+  bool isOutsideTargetContext(SourceLocation Loc) const {
+return !SM.isPointWithin(Loc, TargetContextRng.getBegin(),
+ TargetContextRng.getEnd());
+  }
+  bool isExtractable() { return TargetRng.isValid() && TargetContext; }
+
+  tooling::Replacement replaceWithFuncCall(llvm::StringRef FuncName) const;
+  tooling::Replacement createFunctionDefinition(llvm::StringRef FuncName) const;
+  // The function inside which our target resides.
+  const FunctionDecl *TargetContext;
+
+private:
+  const Node *CommonAnc;
+  const SourceManager &SM;
+  const ASTContext &Ctx;
+  // The range of the code being extracted.
+  SourceRange TargetRng;
+  SourceRange TargetContextRng;
+
+  SourceRange computeTargetRange() const;
+};
+
+const FunctionDecl *computeTargetContext(const Node *CommonAnc) {
+  // Walk up the SelectionTree until we find a function Decl
+  for (const Node *CurNode = CommonAnc; CurNode; CurNode = CurNode->Parent) {
+if (const FunctionDecl *FD = CurNode->ASTNode.get()) {
+  // FIXME: Support extraction from methods.
+  if (CurNode->ASTNode.get())
+return nullptr;
+  return FD;
+}
+  }
+  return nullptr;
+}
+
+ExtractionTarget::ExtractionTarget(const Node *CommonAnc,
+   const SourceManager &SM,
+   const ASTContext &Ctx)
+: CommonAnc(CommonAnc), SM(SM), Ctx(Ctx) {
+  TargetRng = computeTargetRange();
+  if ((TargetContext = computeTargetContext(CommonAnc)))
+TargetContextRng =
+TargetContext->getSourceRange(); // TODO: Use toHalfOpenFileRange?
+}
+
+// TODO: Describe how this works
+SourceRange ExtractionTarget::computeTargetRange() const {
+  const LangOptions &LangOpts = Ctx.getLangOpts();
+  if (!CommonAnc)
+return SourceRange();
+  if (CommonAnc->Selected == SelectionTree::Selection::Complete)
+return *toHalfOpenFileRange(SM, LangOpts,
+CommonAnc->ASTNode.getSourceRange());
+  // FIXME: Bail out when it's partial selected. Wait for selectiontree
+  // semicolon fix.
+  if (CommonAnc->Selected == SelectionTree::Selection::Partial &&
+  !CommonAnc->ASTNode

[PATCH] D65050: [SemaTemplate] Mark a function type as dependent when its parameter list contains pack expansion

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> this looks like it could be a Core Issue

I think the issue is clang-specific. clang splits the standard notion of a 
dependent type into two separate bits, for the sake of diagnostics: 
`isDependentType()`, and `isInstantiationDependentType()`.  
`isInstantiationDependentType()` reflects the actual standard definition of a 
dependent type; `isDependentType()` is a type that can actually vary across 
instantiations.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65050/new/

https://reviews.llvm.org/D65050



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Sam McCall via Phabricator via cfe-commits]

sammccall marked 2 inline comments as done.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/Selection.cpp:50
+  S.StartOffset = SM.getFileOffset(Tok.location());
+  S.EndOffset = S.StartOffset + Tok.length();
+  if (S.StartOffset >= SelBegin && S.EndOffset <= SelEnd)

SureYeaah wrote:
> Would this work correctly for nested templates? Or do we need to use the 
> specialized token length function that we use for toHalfOpenFileRange?
This uses the token list as an intermediary for matching selected chars with 
AST nodes. TokenBuffer will indeed by default lex `>>` as a right shift. So 
we're buggy here, but I think it *mostly* doesn't matter.

If it's a double template:
 - the innermost template will claim it first, if the template range touches 
the selection. Problem: if only the first > is selected, the inner template 
will only be partially selected.
 - the outermost template will not get to claim it at all (if the inner 
template range touches the selection). Problem: if this is the *only* part of 
the outer template that's selected, it will be marked unselected. (This should 
be rare)
 - If the inner template doesn't touch the selection, then the outer template 
will be selected but only partially, which is actually correct.

Examples:
```
a>
 ~  b=partial (correct)
    b=partial (incorrect: b=complete) <-- this is the worst case
~~~ a=complete,b=complete (correct)
  ~ a=partial (correct)
 ~~ b=partial (incorrect: a=partial,b=partial)
```

I'll send a followup to fix this case tomorrow (I think we can just always 
split the token in half) but I don't think it's critical.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65486/new/

https://reviews.llvm.org/D65486



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65511: Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006)

[Reid Kleckner via Phabricator via cfe-commits]

rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm




Comment at: clang/lib/Sema/SemaDeclCXX.cpp:11545
+for (CXXMethodDecl *M : WorkList) {
+  DefineImplicitSpecialMember(*this, M, M->getLocation());
+  ActOnFinishInlineFunctionDef(M);

hans wrote:
> rnk wrote:
> > Do we need to do this until fixpoint? Suppose a dllexported implicit 
> > special member triggers a template instantiation, and the template has a 
> > dllexported defaulted special member, something like:
> > ```
> > struct Bar { Bar(); };
> > template  struct Foo { __declspec(dllexport) Foo() = default; 
> > Bar obj; };
> > struct Baz {
> >... not sure how to trigger instantiation
> > };
> > ```
> I think that should work, and that's why the function is written to be 
> re-entrant by having a local worklist. If it triggers a template 
> instantiation, ActOnFinishCXXNonNestedClass should get called for the newly 
> instantiated class. But I'm also not sure how to write a test case that would 
> trigger it.
Right, I see. Nevermind then.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65511/new/

https://reviews.llvm.org/D65511



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r367453 - [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Sam McCall via cfe-commits]

Author: sammccall
Date: Wed Jul 31 10:52:40 2019
New Revision: 367453

URL: http://llvm.org/viewvc/llvm-project?rev=367453&view=rev
Log:
[clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

Summary:
Whitespace and comments are a clear bugfix: selecting some
comments/space near a statement doesn't mean you're selecting the
surrounding block.

Semicolons are less obvious, but for similar reasons: these tokens
aren't actually claimed by any AST node (usually), so an AST-based model
like SelectionTree shouldn't take them into account.

Callers may still sometimes care about semis of course:
 - when the selection is an expr with a non-expr parent, selection of
   the semicolon indicates intent to select the statement.
 - when a statement with a trailing semi is selected, we need to know
   its range to ensure it can be removed.
SelectionTree may or may not play a role here, but these are separate questions
from its core function of describing which AST nodes were selected.

The mechanism here is the TokenBuffer from syntax-trees. We use it in a
fairly low-level way (just to get boundaries of raw spelled tokens). The
actual mapping of AST nodes to coordinates continues to use the (fairly
mature) SourceLocation based logic. TokenBuffer/Syntax trees
don't currently offer an alternative to getFileRange(), I think.

Reviewers: SureYeaah, kadircet

Subscribers: MaskRay, jkorous, arphaman, cfe-commits, ilya-biryukov

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65486

Modified:
clang-tools-extra/trunk/clangd/Selection.cpp
clang-tools-extra/trunk/clangd/Selection.h
clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
clang-tools-extra/trunk/clangd/unittests/SelectionTests.cpp

Modified: clang-tools-extra/trunk/clangd/Selection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Selection.cpp?rev=367453&r1=367452&r2=367453&view=diff
==
--- clang-tools-extra/trunk/clangd/Selection.cpp (original)
+++ clang-tools-extra/trunk/clangd/Selection.cpp Wed Jul 31 10:52:40 2019
@@ -17,6 +17,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
+#include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -28,39 +29,91 @@ namespace {
 using Node = SelectionTree::Node;
 using ast_type_traits::DynTypedNode;
 
-// Stores a collection of (possibly-overlapping) integer ranges.
-// When new ranges are added, hit-tests them against existing ones.
-class RangeSet {
+// Identifies which tokens are selected, and evaluates claims of source ranges
+// by AST nodes. Tokens may be claimed only once: first-come, first-served.
+class SelectedTokens {
 public:
-  // Returns true if any new offsets are covered.
-  // This is naive (linear in number of successful add() calls), but ok for 
now.
-  bool add(unsigned Begin, unsigned End) {
-assert(std::is_sorted(Ranges.begin(), Ranges.end()));
-assert(Begin < End);
-
-if (covered(Begin, End))
-  return false;
-auto Pair = std::make_pair(Begin, End);
-Ranges.insert(llvm::upper_bound(Ranges, Pair), Pair);
-return true;
+  SelectedTokens(llvm::ArrayRef Spelled, const SourceManager 
&SM,
+ unsigned SelBegin, unsigned SelEnd)
+  : SelBegin(SelBegin), SelEnd(SelEnd) {
+// Extract bounds and selected-ness for all tokens spelled in the file.
+Tokens.reserve(Spelled.size());
+for (const auto& Tok : Spelled) {
+  // As well as comments, don't count semicolons as real tokens.
+  // They're not properly claimed as expr-statement is missing from the 
AST.
+  if (Tok.kind() == tok::comment || Tok.kind() == tok::semi)
+continue;
+
+  Tokens.emplace_back();
+  TokInfo &S = Tokens.back();
+  S.StartOffset = SM.getFileOffset(Tok.location());
+  S.EndOffset = S.StartOffset + Tok.length();
+  if (S.StartOffset >= SelBegin && S.EndOffset <= SelEnd)
+S.Selected = SelectionTree::Complete;
+  else if (S.EndOffset > SelBegin && S.StartOffset < SelEnd)
+S.Selected = SelectionTree::Partial;
+  else
+S.Selected = SelectionTree::Unselected;
+  S.Claimed = false;
+}
   }
 
-private:
-  bool covered(unsigned Begin, unsigned End) {
-assert(Begin < End);
-for (const auto &R : Ranges) {
-  if (Begin < R.first)
-return false; // The prefix [Begin, R.first) is not covered.
-  if (Begin < R.second) {
-Begin = R.second; // Prefix is covered, truncate the range.
-if (Begin >= End)
-  return true;
+  // Associates any tokens overlapping [Begin, End) with an AST node.
+  // Tokens that were already claimed by another AST node are not claimed 
again.
+  // Returns whether the node is selected in the sense of SelectionTree.
+  SelectionTree::Selection claim(unsigned Begin, unsigne

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
sammccall marked an inline comment as done.
Closed by commit rL367453: [clangd] Ignore semicolons, whitespace, and comments 
in SelectionTree. (authored by sammccall, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65486?vs=212536&id=212626#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65486/new/

https://reviews.llvm.org/D65486

Files:
  clang-tools-extra/trunk/clangd/Selection.cpp
  clang-tools-extra/trunk/clangd/Selection.h
  clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
  clang-tools-extra/trunk/clangd/unittests/SelectionTests.cpp

Index: clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
===
--- clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
+++ clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
@@ -41,7 +41,7 @@
 Tweak::Selection::Selection(ParsedAST &AST, unsigned RangeBegin,
 unsigned RangeEnd)
 : AST(AST), SelectionBegin(RangeBegin), SelectionEnd(RangeEnd),
-  ASTSelection(AST.getASTContext(), RangeBegin, RangeEnd) {
+  ASTSelection(AST.getASTContext(), AST.getTokens(), RangeBegin, RangeEnd) {
   auto &SM = AST.getSourceManager();
   Code = SM.getBufferData(SM.getMainFileID());
   Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
Index: clang-tools-extra/trunk/clangd/Selection.h
===
--- clang-tools-extra/trunk/clangd/Selection.h
+++ clang-tools-extra/trunk/clangd/Selection.h
@@ -35,6 +35,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SELECTION_H
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/PrettyPrinter.h"
+#include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/SmallVector.h"
 
 namespace clang {
@@ -56,8 +57,9 @@
 //
 // SelectionTree tries to behave sensibly in the presence of macros, but does
 // not model any preprocessor concepts: the output is a subset of the AST.
-// Currently comments, directives etc are treated as part of the lexically
-// containing AST node, (though we may want to change this in future).
+//
+// Comments, directives and whitespace are completely ignored.
+// Semicolons are also ignored, as the AST generally does not model them well.
 //
 // The SelectionTree owns the Node structures, but the ASTNode attributes
 // point back into the AST it was constructed with.
@@ -66,11 +68,13 @@
   // Creates a selection tree at the given byte offset in the main file.
   // This is approximately equivalent to a range of one character.
   // (Usually, the character to the right of Offset, sometimes to the left).
-  SelectionTree(ASTContext &AST, unsigned Offset);
+  SelectionTree(ASTContext &AST, const syntax::TokenBuffer &Tokens,
+unsigned Offset);
   // Creates a selection tree for the given range in the main file.
   // The range includes bytes [Start, End).
   // If Start == End, uses the same heuristics as SelectionTree(AST, Start).
-  SelectionTree(ASTContext &AST, unsigned Start, unsigned End);
+  SelectionTree(ASTContext &AST, const syntax::TokenBuffer &Tokens,
+unsigned Start, unsigned End);
 
   // Describes to what extent an AST node is covered by the selection.
   enum Selection {
Index: clang-tools-extra/trunk/clangd/Selection.cpp
===
--- clang-tools-extra/trunk/clangd/Selection.cpp
+++ clang-tools-extra/trunk/clangd/Selection.cpp
@@ -17,6 +17,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
+#include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -28,39 +29,91 @@
 using Node = SelectionTree::Node;
 using ast_type_traits::DynTypedNode;
 
-// Stores a collection of (possibly-overlapping) integer ranges.
-// When new ranges are added, hit-tests them against existing ones.
-class RangeSet {
+// Identifies which tokens are selected, and evaluates claims of source ranges
+// by AST nodes. Tokens may be claimed only once: first-come, first-served.
+class SelectedTokens {
 public:
-  // Returns true if any new offsets are covered.
-  // This is naive (linear in number of successful add() calls), but ok for now.
-  bool add(unsigned Begin, unsigned End) {
-assert(std::is_sorted(Ranges.begin(), Ranges.end()));
-assert(Begin < End);
-
-if (covered(Begin, End))
-  return false;
-auto Pair = std::make_pair(Begin, End);
-Ranges.insert(llvm::upper_bound(Ranges, Pair), Pair);
-return true;
+  SelectedTokens(llvm::ArrayRef Spelled, const SourceManager &SM,
+ unsigned SelBegin, unsigned SelEnd)
+  : SelBegin(SelBegin), SelEnd(SelEnd) {
+// Extract bounds and selected-ness for all tokens spelled in the file

[PATCH] D63932: [GlobalDCE] Dead Virtual Function Elimination

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

In D63932#1608235 , @ostannard wrote:

> > - Take the example from my earlier message, give the "main executable" and 
> > "DSO" hidden visibility, build the "main executable" with LTO and the "DSO" 
> > without LTO, and statically link them both into the same executable. We run 
> > into the same problem where the Plugin1 vtable is potentially not 
> > referenced and thus misoptimised. Yes, this is a violation of the LTO 
> > visibility rules, but the example shows that we only detect it sometimes. I 
> > think that if we did want to detect cases where the LTO visibility rules 
> > are clearly being violated, the outcome should be to issue a diagnostic and 
> > not to silently proceed with optimizations disabled, since the violation 
> > might be masking other undetected issues. That really seems orthogonal to 
> > this patch, though.
>
> As you say, this is a violation of the LTO visibility rules, so 
> `[[clang::lto_visibility_public]]` must be used. I've gated this optimisation 
> behind `-fwhole-program-vtables`, which if I've understood 
> https://clang.llvm.org/docs/LTOVisibility.html correctly, is effectively the 
> user asserting to the compiler that they've followed the LTO visility rules 
> correctly.


Yes, that's correct.

>> - Imagine linking part of a program with ld -r with LTO -- all symbols 
>> including vtable symbols will appear to be externally visible, which is not 
>> necessarily a violation of the LTO visibility rules because they may not be 
>> used externally in the final link. So we end up pessimising unnecessarily.
> 
> I'm not really familiar with partial linking, is there any good documentation 
> on how it is supposed to interact with LTO?

I'm not aware of any. The way that I think about it is that a partial link 
operation with LTO inputs can still produce an LTO unit, but that LTO unit may 
not be combined with other LTO units, either by passing bitcode files directly 
to the final link or by adding another `ld -r` output with an LTO unit to the 
final link.

> I've tried to make the changed to vcall_visibility as similar to the normal 
> LTO internalisation process as possible, it happens at the same time and 
> under the same conditions. If partial linking prevents normal 
> internalisation, which will in turn prevent most of the existing 
> optimisations done by GlobalDCE, then surely it should also prevent 
> internalisation of vcall_visibility?

Partial linking will indeed prevent dropping the virtual functions, but it 
should not prevent clearing the pointer to the virtual function in the vtable. 
The linker should then be able to drop the virtual function body as part of 
`--gc-sections` during the final link.

>> I gave this some more thought and it seems that the frontend has all of the 
>> information required to make a determination about whether to allow VFE, 
>> without needing to teach LTO to relax visibility. We can make the frontend 
>> do this:
>> 
>> - If -flto was passed (see CodeGenOptions::PrepareForLTO), attach "allow 
>> VFE" metadata if class has hidden LTO visibility.
>> - Otherwise, attach "allow VFE" metadata if class is not isExternallyVisible.
>> 
>>   Now the behaviour of GlobalDCE can be made conditional on the "allow VFE" 
>> metadata alone. This also has the advantage of simplifying the IR by making 
>> "allow VFE" a boolean rather than a tri-state as it is now.
> 
> The problem with that is that GlobalDCE is still run in the pre-linking 
> pipeline when emiting an LTO object, because it can remove code/data which 
> already has internal linkage.

Right, of course. Sorry, I forgot about that. It seems that if we want to allow 
VFE on internal linkage types without LTO, we would still need the tri-state.

> To make this work, we'd have to do one of:
> 
> - Tell GlobalDCE whether it is running in LTO post-linking or not, so it can 
> avoid doing VFE before internalisation.   This breaks the idea that the IR 
> contains all the information needed to determine if an optimisation is legal 
> or not.
> - Remove the pre-linking runs of GlobalDCE when doing LTO. This will result 
> in more known-dead code reaching the LTO link stage, and results in a pass 
> which is only valid at certain points in the pipeline.
> - Split VFE out of GlobalDCE. This would result in worse optimisation, 
> because chains of dependencies involving both virtual calls and regular 
> references won't be followed fully.

I think I would favour something closer to your first suggestion, but instead 
of telling GlobalDCE specifically about this, we represent the "post-link" flag 
in the IR (e.g. as a module flag) in order to keep the IR self-contained. LTO 
would then be taught to add this flag at the right time, and the logic inside 
GlobalDCE would be:

- If post-link flag not set, allow VFE if linkage <= TranslationUnit.
- If post-link flag set, allow VFE if linkage <= LinkageUnit.

This would also help addres

[PATCH] D65527: Avoid assemble step in verbose-output-quoting.c

[Yuanfang Chen via Phabricator via cfe-commits]

ychen created this revision.
ychen added a reviewer: hans.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65527

Files:
  clang/test/Driver/verbose-output-quoting.c


Index: clang/test/Driver/verbose-output-quoting.c
===
--- clang/test/Driver/verbose-output-quoting.c
+++ clang/test/Driver/verbose-output-quoting.c
@@ -1,8 +1,8 @@
 // REQUIRES: shell
-// RUN: %clang --verbose -DSPACE="a b"  -c %s 2>&1 | FileCheck 
-check-prefix=SPACE -strict-whitespace %s
-// RUN: %clang --verbose -DQUOTES=\"\"  -c %s 2>&1 | FileCheck 
-check-prefix=QUOTES-strict-whitespace %s
-// RUN: %clang --verbose -DBACKSLASH=\\ -c %s 2>&1 | FileCheck 
-check-prefix=BACKSLASH -strict-whitespace %s
-// RUN: %clang --verbose -DDOLLAR=\$-c %s 2>&1 | FileCheck 
-check-prefix=DOLLAR-strict-whitespace %s
+// RUN: %clang --verbose -DSPACE="a b"  -S %s 2>&1 | FileCheck 
-check-prefix=SPACE -strict-whitespace %s
+// RUN: %clang --verbose -DQUOTES=\"\"  -S %s 2>&1 | FileCheck 
-check-prefix=QUOTES-strict-whitespace %s
+// RUN: %clang --verbose -DBACKSLASH=\\ -S %s 2>&1 | FileCheck 
-check-prefix=BACKSLASH -strict-whitespace %s
+// RUN: %clang --verbose -DDOLLAR=\$-S %s 2>&1 | FileCheck 
-check-prefix=DOLLAR-strict-whitespace %s
 
 // SPACE: -cc1 {{.*}} -D "SPACE=a b"
 // QUOTES: -cc1 {{.*}} -D "QUOTES=\"\""


Index: clang/test/Driver/verbose-output-quoting.c
===
--- clang/test/Driver/verbose-output-quoting.c
+++ clang/test/Driver/verbose-output-quoting.c
@@ -1,8 +1,8 @@
 // REQUIRES: shell
-// RUN: %clang --verbose -DSPACE="a b"  -c %s 2>&1 | FileCheck -check-prefix=SPACE -strict-whitespace %s
-// RUN: %clang --verbose -DQUOTES=\"\"  -c %s 2>&1 | FileCheck -check-prefix=QUOTES-strict-whitespace %s
-// RUN: %clang --verbose -DBACKSLASH=\\ -c %s 2>&1 | FileCheck -check-prefix=BACKSLASH -strict-whitespace %s
-// RUN: %clang --verbose -DDOLLAR=\$-c %s 2>&1 | FileCheck -check-prefix=DOLLAR-strict-whitespace %s
+// RUN: %clang --verbose -DSPACE="a b"  -S %s 2>&1 | FileCheck -check-prefix=SPACE -strict-whitespace %s
+// RUN: %clang --verbose -DQUOTES=\"\"  -S %s 2>&1 | FileCheck -check-prefix=QUOTES-strict-whitespace %s
+// RUN: %clang --verbose -DBACKSLASH=\\ -S %s 2>&1 | FileCheck -check-prefix=BACKSLASH -strict-whitespace %s
+// RUN: %clang --verbose -DDOLLAR=\$-S %s 2>&1 | FileCheck -check-prefix=DOLLAR-strict-whitespace %s
 
 // SPACE: -cc1 {{.*}} -D "SPACE=a b"
 // QUOTES: -cc1 {{.*}} -D "QUOTES=\"\""
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65511: Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006)

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:11545
+for (CXXMethodDecl *M : WorkList) {
+  DefineImplicitSpecialMember(*this, M, M->getLocation());
+  ActOnFinishInlineFunctionDef(M);

rnk wrote:
> hans wrote:
> > rnk wrote:
> > > Do we need to do this until fixpoint? Suppose a dllexported implicit 
> > > special member triggers a template instantiation, and the template has a 
> > > dllexported defaulted special member, something like:
> > > ```
> > > struct Bar { Bar(); };
> > > template  struct Foo { __declspec(dllexport) Foo() = default; 
> > > Bar obj; };
> > > struct Baz {
> > >... not sure how to trigger instantiation
> > > };
> > > ```
> > I think that should work, and that's why the function is written to be 
> > re-entrant by having a local worklist. If it triggers a template 
> > instantiation, ActOnFinishCXXNonNestedClass should get called for the newly 
> > instantiated class. But I'm also not sure how to write a test case that 
> > would trigger it.
> Right, I see. Nevermind then.
This works on latest MSVC:
```
$ cat test.cc
struct Bar { Bar(); };
template  struct Foo { __declspec(dllexport) Foo() = default; Bar 
b; };
template class Foo;

$ cl /c /Z7 test.cc   <-- crashes if using clang-cl

$ lib test.obj /def

$ cat test2.cc
struct Bar { Bar() { } };
template  struct Foo { __declspec(dllimport) Foo() = default; Bar 
b; };
int main() {
  Foo f;
  return 0;
}

$ cl /c /Z7 test2.cc

$ link test.lib test2.cc /DEBUG
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65511/new/

https://reviews.llvm.org/D65511



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65308: [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi updated this revision to Diff 212634.
plotfi added a comment.

trying to re-land, changing TY_ObjCXXHeader to  TY_PP_ObjCXXHeader,


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65308/new/

https://reviews.llvm.org/D65308

Files:
  clang/include/clang/Driver/Types.def
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/Types.cpp

Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -18,15 +18,14 @@
 
 struct TypeInfo {
   const char *Name;
-  const char *Flags;
   const char *TempSuffix;
   ID PreprocessedType;
   const llvm::SmallVector Phases;
 };
 
 static const TypeInfo TypeInfos[] = {
-#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, FLAGS, ...) \
-  { NAME, FLAGS, TEMP_SUFFIX, TY_##PP_TYPE, { __VA_ARGS__ }, },
+#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, ...) \
+  { NAME, TEMP_SUFFIX, TY_##PP_TYPE, { __VA_ARGS__ }, },
 #include "clang/Driver/Types.def"
 #undef TYPE
 };
@@ -90,7 +89,15 @@
 }
 
 bool types::canTypeBeUserSpecified(ID Id) {
-  return strchr(getInfo(Id).Flags, 'u');
+  static const clang::driver::types::ID kStaticLangageTypes[] = {
+  TY_CUDA_DEVICE,   TY_HIP_DEVICE,TY_PP_CHeader,
+  TY_PP_ObjCHeader, TY_PP_CXXHeader,  TY_PP_ObjCXXHeader,
+  TY_PP_CXXModule,  TY_LTO_IR,TY_LTO_BC,
+  TY_Plist, TY_RewrittenObjC, TY_RewrittenLegacyObjC,
+  TY_Remap, TY_PCH,   TY_Object,
+  TY_Image, TY_dSYM,  TY_Dependencies,
+  TY_CUDA_FATBIN,   TY_HIP_FATBIN};
+  return !llvm::is_contained(kStaticLangageTypes, Id);
 }
 
 bool types::appendSuffixForType(ID Id) {
Index: clang/include/clang/Driver/Types.h
===
--- clang/include/clang/Driver/Types.h
+++ clang/include/clang/Driver/Types.h
@@ -20,7 +20,7 @@
 namespace types {
   enum ID {
 TY_INVALID,
-#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, FLAGS, ...) TY_##ID,
+#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, ...) TY_##ID,
 #include "clang/Driver/Types.def"
 #undef TYPE
 TY_LAST
Index: clang/include/clang/Driver/Types.def
===
--- clang/include/clang/Driver/Types.def
+++ clang/include/clang/Driver/Types.def
@@ -29,76 +29,73 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The fifth value is a string containing option flags. Valid values:
-//  u - The type can be user specified (with -x).
-
-// The sixth value is a variadic list of phases for each type. Eventually the
+// The final value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i", "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c", "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cl",   CL,   PP_C,"cl","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu","" , phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu","" , phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c",  ObjC, PP_ObjC, "m", "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++-cpp-output",   PP_CXX,   INVALID, "ii","u", phase

[PATCH] D64811: Warn when NumParams overflows

[Mark de Wever via Phabricator via cfe-commits]

Mordante marked an inline comment as done.
Mordante added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:6673
+  // Avoid exceeding the maximum function parameters
+  // See https://bugs.llvm.org/show_bug.cgi?id=19607
+  if (ParamInfo.size() > Type::getMaxNumParams()) {

rjmccall wrote:
> rjmccall wrote:
> > We don't usually cite bugs like this in the main source code except as 
> > "there's a bug with this, here's where we tracking fixing it".  The comment 
> > explains the purpose of the diagnostic well enough (but please include a 
> > period).
> > 
> > Can you just drop the excess arguments here instead of cutting off parsing?
> Or actually — let's move this out of the parser entirely, because (unlike 
> prototype scope depth) we actually need to diagnose it in Sema as well 
> because of variadic templates.  `Sema::BuildFunctionType` seems like the 
> right place.
> 
> Also, can you `static_assert` that function declarations support at least as 
> many parameter declarations as we allow in types?
I tried your suggestion to move the test to `Sema::BuildFunctionType` but that 
function is only used for templates so it doesn't show the warning for other 
cases. Also the error generated will also print the 
`note_ovl_candidate_substitution_failure` diagnostic making the output rather 
unreadable. So I'll look for a better way to handle the variadic template case.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64811/new/

https://reviews.llvm.org/D64811



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Harlan Haskins via Phabricator via cfe-commits]

harlanhaskins created this revision.
harlanhaskins added reviewers: arphaman, bruno.
Herald added subscribers: lldb-commits, cfe-commits, jsji, kadircet, 
dexonsmith, jkorous, MaskRay, kbarton, nemanjai.
Herald added a reviewer: martong.
Herald added a reviewer: shafik.
Herald added projects: clang, LLDB.
harlanhaskins edited the summary of this revision.
Herald added subscribers: wuzish, ormris, rnkovacs.

Currently, clang's FileManager uses NULL as an indicator that a particular file
did not exist, but would not propagate errors like permission issues. Instead,
teach FileManager to use llvm::ErrorOr internally and return rich errors for
failures.

This patch updates the existing API and updates the callers throughout clang.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65534

Files:
  clang-tools-extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp
  clang-tools-extra/clang-change-namespace/tool/ClangChangeNamespace.cpp
  clang-tools-extra/clang-include-fixer/IncludeFixer.cpp
  clang-tools-extra/clang-move/Move.cpp
  clang-tools-extra/clang-move/tool/ClangMove.cpp
  clang-tools-extra/clang-reorder-fields/tool/ClangReorderFields.cpp
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clangd/ClangdUnit.cpp
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/modularize/ModularizeUtilities.cpp
  clang/include/clang/Basic/FileManager.h
  clang/lib/ARCMigrate/FileRemapper.cpp
  clang/lib/ARCMigrate/ObjCMT.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/Basic/FileManager.cpp
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/ASTUnit.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Frontend/InitHeaderSearch.cpp
  clang/lib/Frontend/PrecompiledPreamble.cpp
  clang/lib/Frontend/Rewrite/FrontendActions.cpp
  clang/lib/Frontend/TextDiagnostic.cpp
  clang/lib/Lex/HeaderMap.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/ModuleMap.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/GlobalModuleIndex.cpp
  clang/lib/Serialization/ModuleManager.cpp
  clang/lib/Tooling/Core/Replacement.cpp
  clang/lib/Tooling/Refactoring.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/tools/clang-import-test/clang-import-test.cpp
  clang/tools/clang-refactor/ClangRefactor.cpp
  clang/tools/clang-refactor/TestSupport.cpp
  clang/tools/clang-rename/ClangRename.cpp
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/Indexing.cpp
  clang/unittests/Basic/FileManagerTest.cpp
  clang/unittests/Lex/HeaderSearchTest.cpp
  clang/unittests/Lex/PPCallbacksTest.cpp
  clang/unittests/Tooling/RefactoringTest.cpp
  clang/unittests/Tooling/RewriterTestContext.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp

Index: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -247,11 +247,11 @@
 
   bool is_system = true;
   bool is_framework = false;
-  auto *dir =
+  auto dir =
   HS.getFileMgr().getDirectory(module.search_path.GetStringRef());
   if (!dir)
 return error();
-  auto *file = HS.lookupModuleMapFile(dir, is_framework);
+  auto *file = HS.lookupModuleMapFile(*dir, is_framework);
   if (!file)
 return error();
   if (!HS.loadModuleMapFile(file, is_system))
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -908,10 +908,13 @@
   if (file.Write(expr_text, bytes_written).Success()) {
 if (bytes_written == expr_text_len) {
   file.Close();
-  source_mgr.setMainFileID(source_mgr.createFileID(
-  m_compiler->getFileManager().getFile(result_path),
-  SourceLocation(), SrcMgr::C_User));
-  created_main_file = true;
+  if (auto fileEntry =
+  m_compiler->getFileManager().getFile(result_path)) {
+source_mgr.setMainFileID(source_mgr.createFileID(
+*fileEntry,
+SourceLocation(), SrcMgr::C_User));
+created_main_file = true;
+  }
 }
   }
 }
Index: clang/unittests/Tooling/RewriterTestContext.h
===
--- clang/unittests/Tooling/RewriterTestContext.h
+++ clang/unittests/Tooling/RewriterTestContext

[PATCH] D65510: [clangd] Fix implicit template instatiations appearing as topLevelDecls.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdUnit.cpp:68
+  if (const auto *TD = dyn_cast(D))
+return TD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation;
+  return false;

ilya-biryukov wrote:
> We also want to skip `TSK_ExplicitInstantiationDeclaration` and  
> `TSK_ExplicitInstantiationDefinition` here.
> This covers cases like (not sure which one of the two enum values we get, 
> though):
> ```
> template 
> int foo(T) { ... }
> 
> template int foo(int); // we'd rather not traverse these, highlightings will 
> run into the same problems.
> ```
> 
> Semantics I'm describing are roughly similar to `isImplicitInstatiation(D) == 
> !isExplicitInstantion(D)`, where `isExplicitInstantiation` is taken from 
> `CodeComplete.cpp`. (If we ignore `TSK_Undeclared`, which, I believe, should 
> never be encountered in decls passed to HandleTopLevelDecl).
> 
> Please extract the helper from code complete and this one into a separate 
> file (e.g. `clangd/AST.h`) and possibly implement one through the other
> Semantics I'm describing are roughly similar to isImplicitInstatiation(D) == 
> !isExplicitInstantion(D), 

I think there is a typo here, I believe you mean `isImplicitInstantiation(D) == 
!isExplicitSpecialization(D) ` (in CodeComplete.cpp, it checks whether a Decl 
is an explicit **specialization**).



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:219
+R"cpp(
+  class $Class[[Foo]] {
+  public:

instead adding a highlighting test, could we add this testcase to 
`ClangdUnitTests.cpp` instead? 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65510/new/

https://reviews.llvm.org/D65510



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367478 - [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

[Puyan Lotfi via cfe-commits]

Author: zer0
Date: Wed Jul 31 13:40:08 2019
New Revision: 367478

URL: http://llvm.org/viewvc/llvm-project?rev=367478&view=rev
Log:
[NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

Second landing attempt: Changed TY_ObjCXXHeader to TY_PP_ObjCXXHeader to fix
-xobjective-c++-header. This time I verified against
preprocessor output.

Dropping the 'u' entry and the entire Flags table from Types.def.
Now it'll be a bit easier to tablegenify this.

Differential Revision: https://reviews.llvm.org/D65308


Modified:
cfe/trunk/include/clang/Driver/Types.def
cfe/trunk/include/clang/Driver/Types.h
cfe/trunk/lib/Driver/Types.cpp

Modified: cfe/trunk/include/clang/Driver/Types.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Types.def?rev=367478&r1=367477&r2=367478&view=diff
==
--- cfe/trunk/include/clang/Driver/Types.def (original)
+++ cfe/trunk/include/clang/Driver/Types.def Wed Jul 31 13:40:08 2019
@@ -29,76 +29,73 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The fifth value is a string containing option flags. Valid values:
-//  u - The type can be user specified (with -x).
-
-// The sixth value is a variadic list of phases for each type. Eventually the
+// The final value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i", "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c", "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cl",   CL,   PP_C,"cl","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu","" , 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu","" , 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi","u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi","u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c",  ObjC, PP_ObjC, "m", "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("c++-cpp-output",   PP_CXX,   INVALID, "ii","u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++",  CXX,  PP_CXX,  "cpp",   "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("objective-c++-cpp-output", PP_ObjCXX,INVALID, "mii",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc++-cpp-output",PP_ObjCXX_Alias, INVALID,  "mii",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c++",ObjCXX,   PP_ObjCXX,   "mm","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("renderscript", RenderScript, PP_C,"rs","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cpp-output",   PP_C, INVALID, "i",  
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("c",C,PP_C,"c",  
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cl",   CL,   PP_C,"cl", 
phases::Preprocess, phases::Compile, 

r367479 - [clang][ARM] Fix msvc arm{64} builtins to use int on LP64 systems.

[Michael J. Spencer via cfe-commits]

Author: mspencer
Date: Wed Jul 31 13:42:28 2019
New Revision: 367479

URL: http://llvm.org/viewvc/llvm-project?rev=367479&view=rev
Log:
[clang][ARM] Fix msvc arm{64} builtins to use int on LP64 systems.

The `InterlockedX_{acq,nf,rel}` functions deal with 32 bits which is long on
MSVC, but int on most other systems.

This also checks that `ReadStatusRegister` and `WriteStatusRegister` have
the correct type on aarch64-darwin.

Differential Revision: https://reviews.llvm.org/D64164

Modified:
cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
cfe/trunk/include/clang/Basic/BuiltinsARM.def
cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp
cfe/trunk/test/CodeGen/ms-intrinsics-other.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=367479&r1=367478&r2=367479&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Wed Jul 31 13:42:28 2019
@@ -102,7 +102,7 @@ TARGET_HEADER_BUILTIN(_BitScanReverse, "
 TARGET_HEADER_BUILTIN(_BitScanForward64, "UcUNi*ULLi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_BitScanReverse64, "UcUNi*ULLi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 
-TARGET_HEADER_BUILTIN(_InterlockedAdd,   "LiLiD*Li","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedAdd,   "NiNiD*Ni","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedAnd64, "LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedDecrement64,   "LLiLLiD*","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64,"LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
@@ -112,9 +112,9 @@ TARGET_HEADER_BUILTIN(_InterlockedIncrem
 TARGET_HEADER_BUILTIN(_InterlockedOr64,  "LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedXor64, "LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 
-TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_acq, "LiLiD*Li", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_rel, "LiLiD*Li", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_nf, "LiLiD*Li", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_acq, "NiNiD*Ni", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_rel, "NiNiD*Ni", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_nf, "NiNiD*Ni", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd8_acq, "ccD*c", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd8_rel, "ccD*c", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd8_nf, "ccD*c", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
@@ -131,9 +131,9 @@ TARGET_HEADER_BUILTIN(_InterlockedExchan
 TARGET_HEADER_BUILTIN(_InterlockedExchange16_acq, "ssD*s",   "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange16_nf,  "ssD*s",   "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange16_rel, "ssD*s",   "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchange_acq,   "LiLiD*Li","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchange_nf,"LiLiD*Li","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchange_rel,   "LiLiD*Li","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchange_acq,   "NiNiD*Ni","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchange_nf,"NiNiD*Ni","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchange_rel,   "NiNiD*Ni","nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64_acq, "LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64_nf,  "LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64_rel, "LLiLLiD*LLi", "nh", 
"intrin.h", ALL_MS_LANGUAGES, "")
@@ -144,9 +144,9 @@ TARGET_HEADER_BUILTIN(_InterlockedCompar
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange16_acq, "ssD*ss", 
"nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange16_nf,  "ssD*ss", 
"nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange16_rel, "ssD*ss", 
"nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_acq,   "LiLiD*LiLi", 
"nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TA

[PATCH] D64164: [clang][ARM] Fix msvc arm{64} builtins to use int on LP64 systems.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367479: [clang][ARM] Fix msvc arm{64} builtins to use int on 
LP64 systems. (authored by mspencer, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64164?vs=207907&id=212658#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64164/new/

https://reviews.llvm.org/D64164

Files:
  cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
  cfe/trunk/include/clang/Basic/BuiltinsARM.def
  cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp
  cfe/trunk/test/CodeGen/ms-intrinsics-other.c

Index: cfe/trunk/include/clang/Basic/BuiltinsARM.def
===
--- cfe/trunk/include/clang/Basic/BuiltinsARM.def
+++ cfe/trunk/include/clang/Basic/BuiltinsARM.def
@@ -221,9 +221,9 @@
 TARGET_HEADER_BUILTIN(_InterlockedOr64,  "LLiLLiD*LLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedXor64, "LLiLLiD*LLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 
-TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_acq, "LiLiD*Li", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_rel, "LiLiD*Li", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_nf, "LiLiD*Li", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_acq, "NiNiD*Ni", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_rel, "NiNiD*Ni", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd_nf, "NiNiD*Ni", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd8_acq, "ccD*c", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd8_rel, "ccD*c", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchangeAdd8_nf, "ccD*c", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
@@ -240,9 +240,9 @@
 TARGET_HEADER_BUILTIN(_InterlockedExchange16_acq, "ssD*s",   "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange16_nf,  "ssD*s",   "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange16_rel, "ssD*s",   "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchange_acq,   "LiLiD*Li","nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchange_nf,"LiLiD*Li","nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedExchange_rel,   "LiLiD*Li","nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchange_acq,   "NiNiD*Ni","nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchange_nf,"NiNiD*Ni","nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedExchange_rel,   "NiNiD*Ni","nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64_acq, "LLiLLiD*LLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64_nf,  "LLiLLiD*LLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedExchange64_rel, "LLiLLiD*LLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
@@ -253,9 +253,9 @@
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange16_acq, "ssD*ss", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange16_nf,  "ssD*ss", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange16_rel, "ssD*ss", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_acq,   "LiLiD*LiLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_nf,"LiLiD*LiLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_rel,   "LiLiD*LiLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_acq,   "NiNiD*NiNi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_nf,"NiNiD*NiNi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_InterlockedCompareExchange_rel,   "NiNiD*NiNi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange64_acq, "LLiLLiD*LLiLLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange64_nf,  "LLiLLiD*LLiLLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedCompareExchange64_rel, "LLiLLiD*LLiLLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
@@ -266,9 +266,9 @@
 TARGET_HEADER_BUILTIN(_InterlockedOr16_acq, "ssD*s",   "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_InterlockedOr16_nf,  "ssD*s",   "nh", "intrin.h", ALL_MS_LANGUAGES, ""

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Davide Italiano via Phabricator via cfe-commits]

davide added a comment.

Really on the lldb side, Jonas is the right person to review this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Davide Italiano via Phabricator via cfe-commits]

davide added a comment.

[and Raphael for the clang vendor bits]


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64671: [clang-tidy] New check: misc-init-local-variables

[Jussi Pakkanen via Phabricator via cfe-commits]

jpakkane updated this revision to Diff 212664.
jpakkane added a comment.
Herald added subscribers: kbarton, nemanjai.

Renamed to cppcoreguidelines-init-variables.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64671/new/

https://reviews.llvm.org/D64671

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/cppcoreguidelines-init-variables.cpp

Index: clang-tools-extra/test/clang-tidy/cppcoreguidelines-init-variables.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/cppcoreguidelines-init-variables.cpp
@@ -0,0 +1,104 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-init-variables %t
+
+#include 
+
+#define DO_NOTHING(x) ((void)x)
+
+// Ensure that function declarations are not changed.
+void some_func(int x, double d, bool b, const char *p);
+
+// Ensure that function arguments are not changed
+int identity_function(int x) {
+  return x;
+}
+
+int do_not_modify_me;
+
+typedef struct {
+  int unaltered1;
+  int unaltered2;
+} UnusedStruct;
+
+typedef int my_int_type;
+#define MACRO_INT int
+#define FULL_DECLARATION() int macrodecl;
+
+template 
+void template_test_function() {
+  T t;
+  int uninitialized;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'uninitialized' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int uninitialized = 0;{{$}}
+
+  DO_NOTHING(t);
+  DO_NOTHING(uninitialized);
+}
+
+void init_unit_tests() {
+  int x;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'x' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int x = 0;{{$}}
+  int32_t sized_var;
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: variable 'sized_var' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int32_t sized_var = 0;{{$}}
+  my_int_type myint;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: variable 'myint' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  my_int_type myint = 0;{{$}}
+
+  MACRO_INT macroint;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: variable 'macroint' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  MACRO_INT macroint = 0;{{$}}
+  FULL_DECLARATION();
+
+  int x0 = 1, x1, x2 = 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: variable 'x1' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int x0 = 1, x1 = 0, x2 = 2;{{$}}
+  int y0, y1 = 1, y2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'y0' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-MESSAGES: :[[@LINE-2]]:19: warning: variable 'y2' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int y0 = 0, y1 = 1, y2 = 0;{{$}}
+  int hasval = 42;
+
+  float f;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: variable 'f' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  float f = (0.0/0.0);{{$}}
+  float fval = 85.0;
+  double d;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: variable 'd' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  double d = (0.0/0.0);{{$}}
+  double dval = 99.0;
+
+  bool b;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: variable 'b' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  bool b = 0;{{$}}
+  bool bval = true;
+
+  const char *ptr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: variable 'ptr' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  const char *ptr = nullptr;{{$}}
+  const char *ptrval = "a string";
+
+  UnusedStruct u;
+
+  DO_NOTHING(x);
+  DO_NOTHING(sized_var);
+  DO_NOTHING(myint);
+  DO_NOTHING(macroint);
+  DO_NOTHING(macrodecl);
+  DO_NOTHING(x0);
+  DO_NOTHING(x1);
+  DO_NOTHING(x2);
+  DO_NOTHING(y0);
+  DO_NOTHING(y1);
+  DO_NOTHING(y2);
+  DO_NOTHING(hasval);
+  DO_NOTHING(f);
+  DO_NOTHING(fval);
+  DO_NOTHING(d);
+  DO_NOTHING(dval);
+  DO_NOTHING(b);
+  DO_NOTHING(bval);
+  DO_NOTHING(ptr);
+  DO_NOTHING(ptrval);
+  DO_NOTHING(u);
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -107,6 +107,7 @@
cppcoreguidelines-avoid-magic-numbers (redirects to readability-magic-numbers) 
cppcoreguidelines-c-copy-assignment-signature (redirects to misc-unconventional-assign-operator) 
cppcoreguidelines-explicit

[PATCH] D64146: [ConstExprPreter][WIP] Initial patch for the constexpr interpreter

[Nandor Licker via Phabricator via cfe-commits]

nand marked 40 inline comments as done.
nand added a comment.

I have applied most of the changes you suggested to my HEAD which had 
significantly more functionality, including a replacement of Opcodes.in with 
TableGen.
Quite a few of your concerns are answered by the features I have added between 
submitting the patch and now. The interpreter now stands at ~6k LOC.

Should I update the diff with an interpreter trimmed down to the functionality 
of the current diff (~3k LOC) or post the full interpreter now? What would be 
easier to review?




Comment at: clang/lib/AST/ExprVM/Compiler.cpp:88
+  Params.insert({ParamDecl, ParamOffset});
+  ParamOffset += align(Size);
+  Args.push_back(*T);

rsmith wrote:
> What happens if this overflows (due to many large local variables)?
Overflow happens here if a function takes more than a few million arguments. I 
think clang would die before it gets here.



Comment at: clang/lib/AST/ExprVM/Compiler.cpp:488-503
+Error Compiler::discard(const Expr *DE) {
+  switch (DE->getStmtClass()) {
+  case Stmt::BinaryOperatorClass:
+return discardBinaryOperator(static_cast(DE));
+  default:
+if (auto E = Visit(DE))
+  return E;

rsmith wrote:
> I'm uncomfortable about this: it looks like you're heading towards 
> duplicating a large portion of the bytecode generation depending on whether 
> the result is used. Can we do better somehow? (Eg, in CodeGen, at least for 
> aggregates, we use the same code but track whether the destination is used or 
> not.)
I'd like to do this in a future diff, once we add support for more constructs 
which discard their results.



Comment at: clang/lib/AST/ExprVM/InterpFrame.h:89-90
+  char *Args = nullptr;
+  /// Fixed, initial storage for known local variables.
+  std::unique_ptr Locals;
+};

rsmith wrote:
> Separate allocation for each frame seems wasteful. Have you considered using 
> a slab-allocated stack or similar? (Eg, allocate a large block up front and 
> allocate the locals from that, and allocate more blocks if the first one is 
> exhausted; you can cache the blocks on the `vm::Context` for reuse with no 
> extra round-trips to the heap.)
Yes, I considered allocating this on the stack - I just don't want to add that 
complexity to the interpreter yet. I like to avoid changing this until it 
becomes a noticeable performance problem.



Comment at: clang/lib/AST/ExprVM/Pointer.h:30
+
+/// Describes a memory block - generated once by the compiler.
+struct Descriptor {

rsmith wrote:
> How is this going to work for subobjects? We can't generate the full space of 
> all possible descriptors, as that would be unmanageable for large arrays of 
> complicated types.
Subobjects will have pointers to descriptors embedded into their data - a 
pointer inside a block can follow that chain of descriptors up to the root.



Comment at: clang/lib/AST/ExprVM/Pointer.h:36-39
+  /// Size of the object.
+  unsigned Size;
+  /// Size of an element.
+  unsigned ElemSize;

rsmith wrote:
> Please use a distinct type for representing size-in-the-interpreter, to avoid 
> confusion and bugs when dealing with code that must manage both compile-time 
> sizes and runtime sizes. And please use `CharUnits` for representing 
> sizes-at-runtime.
I've added an alias to be used for the sizes of object as determined by the 
interpreter - CharUnits will be used when interfacing with APValue.



Comment at: clang/lib/AST/ExprVM/Pointer.h:40-49
+  /// Type of the elements.
+  PrimType ElemType;
+  /// Flag indicating if the descriptor is mutable.
+  bool IsMutable = false;
+  /// Flag indicating if the object is an array.
+  bool IsArray = false;
+  /// Flag indicating if the object is a global.

rsmith wrote:
> Consider packing these 5 members into 4 bytes. 
I'd like to avoid packing stuff for now, makes it harder to change things later 
and it's not a performance problem yet.



Comment at: clang/lib/AST/ExprVM/Program.h:105
+  /// Program bytecode.
+  std::vector Code;
+  /// Mapping from bytecode offsets to source locations.

rsmith wrote:
> If `CodePtr` is a plain pointer, using a single flat vector here seems 
> dangerous; you'll have invalidation issues if you ever trigger creation of a 
> `Function` while evaluating, which seems like something that will happen in 
> practice, eg:
> 
> ```
> constexpr int f();
> constexpr int g() { return f(); }
> constexpr int f() { return 0; } // or imported from a module at this point
> constexpr int k = g(); // evaluation of this call triggers generation of code 
> for f
> ```
This wouldn't have been a problem, but the compilation of default constructors 
caused issues. Now the compiler can recursively invoke itself.



Comment at: clang/lib/AST/ExprVM/Program.h:106-107
+

[PATCH] D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi added a comment.

@jkorous DirectoryWatcherTests causes ninja check-clang to hang on my Ubuntu 
18.04 computer. check-clang will not finish and I am forced to killall -9 
DirectoryWatcherTests. My system has 40 threads and this repros on ext4 and 
btrfs.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58418/new/

https://reviews.llvm.org/D58418



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Jan Korous via Phabricator via cfe-commits]

jkorous added inline comments.



Comment at: clang/include/clang/Basic/FileManager.h:143
   ///
-  llvm::StringMap SeenDirEntries;
+  llvm::StringMap, llvm::BumpPtrAllocator>
+  SeenDirEntries;

Maybe we could replace this with some type that has hard-to-use-incorrectly 
interface instead of using `containsValue()`.



Comment at: clang/include/clang/Basic/FileManager.h:217
   ///
-  /// This returns NULL if the file doesn't exist.
+  /// This returns a \c std::error_code if there was an error loading the file.
   ///

Does that mean that it's now safe to assume the value is `!= NULL` in the 
absence of errors?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60943: Delay diagnosing asm constraints that require immediates until after inlining

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

Friendly ping. :-)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60943/new/

https://reviews.llvm.org/D60943



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

In D58418#1609138 , @plotfi wrote:

> @jkorous DirectoryWatcherTests causes ninja check-clang to hang on my Ubuntu 
> 18.04 computer. check-clang will not finish and I am forced to killall -9 
> DirectoryWatcherTests. My system has 40 threads and this repros on ext4 and 
> btrfs.


Hi @plotfi,

Could you please add more details?

The tests seem fine on CentOS 6.9 with Linux 4.19.34-77 on ext4 and also Ubuntu 
build bots (Ubuntu 18.04.1 LTS) seem fine.
http://lab.llvm.org:8011/buildslaves/ps4-buildslave1a

Unfortunately I don't have any Ubuntu system at hand.

Thanks.

Jan


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58418/new/

https://reviews.llvm.org/D58418



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65543: Use library basenames when autolinking on Windows

[Reid Kleckner via Phabricator via cfe-commits]

rnk created this revision.
rnk added reviewers: russell.gallop, thakis, pcc.
Herald added a subscriber: srhines.
Herald added a project: clang.

Otherwise we embed a potentially absolute and potentially relative path
to clang's resource directory into the object file. Object files with
paths embedded in them are fragile and system specific, even when the
path is relative. They cannot be put in an archive and distributed, for
example.

This will require users to add clang's library directory in its resource
directory to the linker libpath, but that is relatively easy compared to
computing the name of the appropriate compiler-rt library, which is
currently architecture dependent.

This is also consistent with how autolinking seems to work for PS4.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65543

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/sanitizer-ld.c

Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -616,16 +616,16 @@
 // RUN: -target x86_64-pc-windows \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-CFI-STATS-WIN64 %s
-// CHECK-CFI-STATS-WIN64: "--dependent-lib={{[^"]*}}clang_rt.stats_client-x86_64.lib"
-// CHECK-CFI-STATS-WIN64: "--dependent-lib={{[^"]*}}clang_rt.stats-x86_64.lib"
+// CHECK-CFI-STATS-WIN64: "--dependent-lib=clang_rt.stats_client-x86_64.lib"
+// CHECK-CFI-STATS-WIN64: "--dependent-lib=clang_rt.stats-x86_64.lib"
 // CHECK-CFI-STATS-WIN64: "--linker-option=/include:__sanitizer_stats_register"
 
 // RUN: %clang -fsanitize=cfi -fsanitize-stats %s -### -o %t.o 2>&1 \
 // RUN: -target i686-pc-windows \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-CFI-STATS-WIN32 %s
-// CHECK-CFI-STATS-WIN32: "--dependent-lib={{[^"]*}}clang_rt.stats_client-i386.lib"
-// CHECK-CFI-STATS-WIN32: "--dependent-lib={{[^"]*}}clang_rt.stats-i386.lib"
+// CHECK-CFI-STATS-WIN32: "--dependent-lib=clang_rt.stats_client-i386.lib"
+// CHECK-CFI-STATS-WIN32: "--dependent-lib=clang_rt.stats-i386.lib"
 // CHECK-CFI-STATS-WIN32: "--linker-option=/include:___sanitizer_stats_register"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -67,11 +67,11 @@
 
 // RUN: %clang_cl -### /FA -fprofile-instr-generate -- %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-INSTR-GENERATE %s
 // RUN: %clang_cl -### /FA -fprofile-instr-generate=/tmp/somefile.profraw -- %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-INSTR-GENERATE-FILE %s
-// CHECK-PROFILE-INSTR-GENERATE: "-fprofile-instrument=clang" "--dependent-lib={{[^"]*}}clang_rt.profile-{{[^"]*}}.lib"
+// CHECK-PROFILE-INSTR-GENERATE: "-fprofile-instrument=clang" "--dependent-lib=clang_rt.profile-{{[^"]*}}.lib"
 // CHECK-PROFILE-INSTR-GENERATE-FILE: "-fprofile-instrument-path=/tmp/somefile.profraw"
 
 // RUN: %clang_cl -### /FA -fprofile-generate -- %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE %s
-// CHECK-PROFILE-GENERATE: "-fprofile-instrument=llvm" "--dependent-lib={{[^"]*}}clang_rt.profile-{{[^"]*}}.lib"
+// CHECK-PROFILE-GENERATE: "-fprofile-instrument=llvm" "--dependent-lib=clang_rt.profile-{{[^"]*}}.lib"
 
 // RUN: %clang_cl -### /FA -fprofile-instr-generate -fprofile-instr-use -- %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-GEN-USE %s
 // RUN: %clang_cl -### /FA -fprofile-instr-generate -fprofile-instr-use=file -- %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-GEN-USE %s
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -772,8 +772,8 @@
 CmdArgs.push_back("-fprofile-instrument=clang");
 if (TC.getTriple().isWindowsMSVCEnvironment()) {
   // Add dependent lib for clang_rt.profile
-  CmdArgs.push_back(Args.MakeArgString("--dependent-lib=" +
-   TC.getCompilerRT(Args, "profile")));
+  CmdArgs.push_back(Args.MakeArgString(
+  "--dependent-lib=" + TC.getCompilerRTBasename(Args, "profile")));
 }
   }
 
@@ -790,8 +790,9 @@
   }
   if (PGOGenArg) {
 if (TC.getTriple().isWindowsMSVCEnvironment()) {
-  CmdArgs.push_back(Args.MakeArgString("--dependent-lib=" +
-   TC.getCompilerRT(Args, "profile")));
+  // Add dependent lib for clang_rt.profile
+  CmdArgs.push_back(Args.MakeArgString(
+  "--dependent-lib=" + TC.getCompilerRTBasename(Args, "profile")));
 }
 if (PGOGenArg->getOptio

[PATCH] D65543: Use library basenames when autolinking on Windows

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

The idea behind embedding the path was that these objects are usually not 
distributed, so things usually just work.

Is there some other way that we could arrange for the linker to search the 
sanitizer library directory automatically? Maybe we could add the path to one 
of the files in `llvm/tools/msbuild`? I guess that wouldn't solve the problem 
for command-line users but maybe that's enough.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65543/new/

https://reviews.llvm.org/D65543



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65545: Handle some fs::remove failures

[JF Bastien via Phabricator via cfe-commits]

jfb created this revision.
jfb added reviewers: Bigcheese, bruno, arphaman, vsapsai.
Herald added subscribers: llvm-commits, cfe-commits, dexonsmith, jkorous, 
hiraditya.
Herald added projects: clang, LLVM.

We have data showing that some modules builds fail in rare cases. We're 
therefore interested in handling sources of failure better, especially when it 
comes to modules. This patch takes us a small step closer to this by handling 
the return code of fs::remove in code that seems like it should. I haven't 
updated all ignored instances of fs::remove, I therefore can't mark it 
LLVM_NODISCARD for now.

This previous patch helps propagate errors: https://reviews.llvm.org/D63518


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65545

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Frontend/PrecompiledPreamble.h
  clang/lib/Frontend/ASTUnit.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/DependencyFile.cpp
  clang/lib/Frontend/PrecompiledPreamble.cpp
  clang/lib/Rewrite/Rewriter.cpp
  clang/lib/Serialization/GlobalModuleIndex.cpp
  clang/tools/driver/cc1gen_reproducer_main.cpp
  llvm/include/llvm/Support/Error.h
  llvm/include/llvm/Support/FileUtilities.h
  llvm/lib/Support/GraphWriter.cpp
  llvm/lib/Support/LockFileManager.cpp
  llvm/lib/Support/Path.cpp
  llvm/lib/Support/ToolOutputFile.cpp

Index: llvm/lib/Support/ToolOutputFile.cpp
===
--- llvm/lib/Support/ToolOutputFile.cpp
+++ llvm/lib/Support/ToolOutputFile.cpp
@@ -25,7 +25,8 @@
 ToolOutputFile::CleanupInstaller::~CleanupInstaller() {
   // Delete the file if the client hasn't told us not to.
   if (!Keep && Filename != "-")
-sys::fs::remove(Filename);
+if (std::error_code EC = sys::fs::remove(Filename))
+  report_fatal_error("Failed removing file \"" + Filename + "\": " + EC.message());
 
   // Ok, the file is successfully written and closed, or deleted. There's no
   // further need to clean it up on signals.
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -1182,9 +1182,10 @@
   if (RenameEC) {
 // If we can't rename, try to copy to work around cross-device link issues.
 RenameEC = sys::fs::copy_file(TmpName, Name);
-// If we can't rename or copy, discard the temporary file.
+// If we can't rename or copy, discard the temporary file, ignoring any
+// further failure.
 if (RenameEC)
-  remove(TmpName);
+  (void)remove(TmpName);
   }
   sys::DontRemoveFileOnSignal(TmpName);
 #endif
Index: llvm/lib/Support/LockFileManager.cpp
===
--- llvm/lib/Support/LockFileManager.cpp
+++ llvm/lib/Support/LockFileManager.cpp
@@ -47,14 +47,15 @@
 /// \param LockFileName The name of the lock file to read.
 ///
 /// \returns The process ID of the process that owns this lock file
-Optional >
+Optional>
 LockFileManager::readLockFile(StringRef LockFileName) {
   // Read the owning host and PID out of the lock file. If it appears that the
   // owning process is dead, the lock file is invalid.
   ErrorOr> MBOrErr =
   MemoryBuffer::getFile(LockFileName);
   if (!MBOrErr) {
-sys::fs::remove(LockFileName);
+if (std::error_code EC = sys::fs::remove(LockFileName))
+  report_fatal_error("Unable to remove invalid lock file \"" + LockFileName + "\": " + EC.message());
 return None;
   }
   MemoryBuffer &MB = *MBOrErr.get();
@@ -71,7 +72,8 @@
   }
 
   // Delete the lock file. It's invalid anyway.
-  sys::fs::remove(LockFileName);
+  if (std::error_code EC = sys::fs::remove(LockFileName))
+report_fatal_error("Unable to remove invalid lock file \"" + LockFileName + "\": " + EC.message());
   return None;
 }
 
@@ -144,7 +146,8 @@
   // released.
   return;
 }
-sys::fs::remove(Filename);
+if (std::error_code EC = sys::fs::remove(Filename))
+  report_fatal_error("Unable to remove unique lock file on signal \"" + Filename + "\": " + EC.message());
 sys::DontRemoveFileOnSignal(Filename);
   }
 
@@ -204,8 +207,9 @@
   // unique lock file, and fail.
   std::string S("failed to write to ");
   S.append(UniqueLockFileName.str());
+  if (std::error_code EC = sys::fs::remove(UniqueLockFileName))
+S.append("also failed to remove the lockfile");
   setError(Out.error(), S);
-  sys::fs::remove(UniqueLockFileName);
   return;
 }
   }
@@ -234,8 +238,12 @@
 // Someone else managed to create the lock file first. Read the process ID
 // from the lock file.
 if ((Owner = readLockFile(LockFileName))) {
-  // Wipe out our unique lock file (it's useless now)
-  sys::fs::remove(UniqueLockFileName);
+  // Wipe out our unique lock file (it's useless now).
+  if ((EC = sys::fs::remove(UniqueLockFileName))) {
+std::string S("fa

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Harlan Haskins via Phabricator via cfe-commits]

harlanhaskins marked 2 inline comments as done.
harlanhaskins added inline comments.



Comment at: clang/include/clang/Basic/FileManager.h:143
   ///
-  llvm::StringMap SeenDirEntries;
+  llvm::StringMap, llvm::BumpPtrAllocator>
+  SeenDirEntries;

jkorous wrote:
> Maybe we could replace this with some type that has hard-to-use-incorrectly 
> interface instead of using `containsValue()`.
You're right, these should store `llvm::ErrorOr` and use 
`std::err::no_such_file_or_directory` as a placeholder instead of `nullptr`.



Comment at: clang/include/clang/Basic/FileManager.h:217
   ///
-  /// This returns NULL if the file doesn't exist.
+  /// This returns a \c std::error_code if there was an error loading the file.
   ///

jkorous wrote:
> Does that mean that it's now safe to assume the value is `!= NULL` in the 
> absence of errors?
That's the intent of these changes, yes, but it should also be documented. 👍


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62525: [Analyzer] Add new visitor to the iterator checkers

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D62525#1607813 , @Szelethus wrote:

> In D62525#1523026 , 
> @baloghadamsoftware wrote:
>
> > The problem is that the transition is added in the top level function but 
> > iterator position adjustments happen in the lower level ones. Data flow is 
> > one-way, top-down. For example, an insertion happens into a vector that 
> > invalidates all the iterators at and after the position where it is 
> > inserted. In this case `handleInsert()` calls a function that iterates all 
> > the active iterator positions and calls other one that invalidates the ones 
> > affected by the insertion. To propagate back the list of iterators 
> > invalidated would be too complex. Increments and decrements are even worse. 
> > Thus here the correct way seems to find the relevant transitions in a 
> > visitor instead of trying to figure out what note tags to add at each 
> > transition.
>
>
> Mhm, I personally find this reasoning sufficient.


Ok, so is it problematic to define a lambda that checks whether an interesting 
iterator is invalidated? Or is it difficult to return the note tag from many 
stack frames in order to finally squeeze it into the transition?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62525/new/

https://reviews.llvm.org/D62525



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added inline comments.



Comment at: clang/include/clang/Basic/FileManager.h:217
   ///
-  /// This returns NULL if the file doesn't exist.
+  /// This returns a \c std::error_code if there was an error loading the file.
   ///

harlanhaskins wrote:
> jkorous wrote:
> > Does that mean that it's now safe to assume the value is `!= NULL` in the 
> > absence of errors?
> That's the intent of these changes, yes, but it should also be documented. 👍
In line with the previous comment, should we just pass a reference then?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Harlan Haskins via Phabricator via cfe-commits]

harlanhaskins added inline comments.



Comment at: clang/include/clang/Basic/FileManager.h:217
   ///
-  /// This returns NULL if the file doesn't exist.
+  /// This returns a \c std::error_code if there was an error loading the file.
   ///

JDevlieghere wrote:
> harlanhaskins wrote:
> > jkorous wrote:
> > > Does that mean that it's now safe to assume the value is `!= NULL` in the 
> > > absence of errors?
> > That's the intent of these changes, yes, but it should also be documented. 👍
> In line with the previous comment, should we just pass a reference then?
I'm fine with doing that, but it would introduce a significant amount more 
churn into this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65534: [clang] Change FileManager to use llvm::ErrorOr instead of null on failure

[Harlan Haskins via Phabricator via cfe-commits]

harlanhaskins updated this revision to Diff 212701.
harlanhaskins added a comment.

Store references instead of raw pointers in FileManger's cache


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65534/new/

https://reviews.llvm.org/D65534

Files:
  clang-tools-extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp
  clang-tools-extra/clang-change-namespace/tool/ClangChangeNamespace.cpp
  clang-tools-extra/clang-include-fixer/IncludeFixer.cpp
  clang-tools-extra/clang-move/Move.cpp
  clang-tools-extra/clang-move/tool/ClangMove.cpp
  clang-tools-extra/clang-reorder-fields/tool/ClangReorderFields.cpp
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clangd/ClangdUnit.cpp
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/modularize/ModularizeUtilities.cpp
  clang/include/clang/Basic/FileManager.h
  clang/lib/ARCMigrate/FileRemapper.cpp
  clang/lib/ARCMigrate/ObjCMT.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/Basic/FileManager.cpp
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/ASTUnit.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Frontend/InitHeaderSearch.cpp
  clang/lib/Frontend/PrecompiledPreamble.cpp
  clang/lib/Frontend/Rewrite/FrontendActions.cpp
  clang/lib/Frontend/TextDiagnostic.cpp
  clang/lib/Lex/HeaderMap.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/ModuleMap.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/GlobalModuleIndex.cpp
  clang/lib/Serialization/ModuleManager.cpp
  clang/lib/Tooling/Core/Replacement.cpp
  clang/lib/Tooling/Refactoring.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/tools/clang-import-test/clang-import-test.cpp
  clang/tools/clang-refactor/ClangRefactor.cpp
  clang/tools/clang-refactor/TestSupport.cpp
  clang/tools/clang-rename/ClangRename.cpp
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/Indexing.cpp
  clang/unittests/Basic/FileManagerTest.cpp
  clang/unittests/Lex/HeaderSearchTest.cpp
  clang/unittests/Lex/PPCallbacksTest.cpp
  clang/unittests/Tooling/RefactoringTest.cpp
  clang/unittests/Tooling/RewriterTestContext.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp

Index: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -247,11 +247,11 @@
 
   bool is_system = true;
   bool is_framework = false;
-  auto *dir =
+  auto dir =
   HS.getFileMgr().getDirectory(module.search_path.GetStringRef());
   if (!dir)
 return error();
-  auto *file = HS.lookupModuleMapFile(dir, is_framework);
+  auto *file = HS.lookupModuleMapFile(*dir, is_framework);
   if (!file)
 return error();
   if (!HS.loadModuleMapFile(file, is_system))
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -908,10 +908,13 @@
   if (file.Write(expr_text, bytes_written).Success()) {
 if (bytes_written == expr_text_len) {
   file.Close();
-  source_mgr.setMainFileID(source_mgr.createFileID(
-  m_compiler->getFileManager().getFile(result_path),
-  SourceLocation(), SrcMgr::C_User));
-  created_main_file = true;
+  if (auto fileEntry =
+  m_compiler->getFileManager().getFile(result_path)) {
+source_mgr.setMainFileID(source_mgr.createFileID(
+*fileEntry,
+SourceLocation(), SrcMgr::C_User));
+created_main_file = true;
+  }
 }
   }
 }
Index: clang/unittests/Tooling/RewriterTestContext.h
===
--- clang/unittests/Tooling/RewriterTestContext.h
+++ clang/unittests/Tooling/RewriterTestContext.h
@@ -56,9 +56,9 @@
 llvm::MemoryBuffer::getMemBuffer(Content);
 InMemoryFileSystem->addFile(Name, 0, std::move(Source));
 
-const FileEntry *Entry = Files.getFile(Name);
-assert(Entry != nullptr);
-return Sources.createFileID(Entry, SourceLocation(), SrcMgr::C_User);
+auto Entry = Files.getFile(Name);
+assert(Entry);
+return Sources.createFileID(*Entry, SourceLocation(), SrcMgr::C_User);
   }
 
   // FIXME: this code is mostly a duplicate of
@@ -73,14 +73,14 @@
 llvm::raw_fd_o

[PATCH] D65549: [Sema] Prevent -Wunused-lambda-capture from generating false positive warnings on templated member function

[Ziang Wan via Phabricator via cfe-commits]

ziangwan created this revision.
ziangwan added reviewers: rsmith, nickdesaulniers, kongyi, pirama, stephenkelly.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is a continuation of https://reviews.llvm.org/D44844 and a potential fix 
for https://bugs.llvm.org/show_bug.cgi?id=36880.

  template 
  class Variant {
  public:
Variant() {
  [this](auto value) { Construct(value); }(5); // false positive warning 
about "this" capture unused.
}
  
  
template 
void Construct(Arg value) {}
  };
  
  
  int main() {
Variant v;
return 0;
  }

Whenever we see a `UnresolvedMemberExpr`, we always mark a this capture 
ODR-used, even if later on it may be resolved to a static member function. The 
trade-off of this fix is that it will leads to false negative in the following 
case:

  template 
  class OverloadedMixFalseNegative {
  public:
OverloadedMixFalseNegative() {
  [this](auto value) { Construct(value); }(5); // warning disappears but 
should happen
}
  
static void Construct(int value) {}
void Construct(float value) {}
  };


Repository:
  rC Clang

https://reviews.llvm.org/D65549

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/SemaCXX/warn-unused-lambda-capture-this.cpp

Index: clang/test/SemaCXX/warn-unused-lambda-capture-this.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-unused-lambda-capture-this.cpp
@@ -0,0 +1,80 @@
+// RUN: %clang_cc1 -fsyntax-only -Wunused-lambda-capture -verify %s
+
+template 
+class TemplatedStatic {
+public:
+  TemplatedStatic() {
+[this](auto value) { Construct(value); }(5); // expected-warning {{lambda capture 'this' is not used}}
+  }
+
+  template 
+  static void Construct(Arg value) {}
+};
+
+template 
+class TemplatedMember {
+public:
+  TemplatedMember() {
+[this](auto value) { Construct(value); }(5);
+  }
+
+  template 
+  void Construct(Arg value) {}
+};
+
+template 
+class OverloadedStatic {
+public:
+  OverloadedStatic() {
+[this](auto value) { Construct(value); }(5); // expected-warning {{lambda capture 'this' is not used}}
+  }
+
+  static void Construct(int value) {}
+  static void Construct(float value) {}
+};
+
+template 
+class OverloadedMember {
+public:
+  OverloadedMember() {
+[this](auto value) { Construct(value); }(5);
+  }
+
+  void Construct(int value) {}
+  void Construct(float value) {}
+};
+
+template 
+class OverloadedMixTrueNegative {
+public:
+  OverloadedMixTrueNegative() {
+[this](auto value) { Construct(value); }(5);
+  }
+
+  void Construct(int value) {}
+  static void Construct(float value) {}
+};
+
+template 
+class OverloadedMixFalseNegative {
+public:
+  OverloadedMixFalseNegative() {
+// Currently we mark this capture as used whenever UnresolvedMemberExpr
+// happens, even if "Construct" will be resolved to the static one.
+// Ideally we should issue 'this' not used warning.
+[this](auto value) { Construct(value); }(5);
+  }
+
+  static void Construct(int value) {}
+  void Construct(float value) {}
+};
+
+int main() {
+  TemplatedStatic t1; // expected-note {{in instantiation of member function 'TemplatedStatic::TemplatedStatic' requested here}}
+  TemplatedMember t2;
+  OverloadedStatic t3; // expected-note {{in instantiation of member function 'OverloadedStatic::OverloadedStatic' requested here}}
+  OverloadedMember t4;
+  OverloadedMixTrueNegative t5;
+  OverloadedMixFalseNegative t6;
+  return 0;
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -5619,6 +5619,17 @@
 *this, dyn_cast(Fn->IgnoreParens()),
 Fn->getBeginLoc());
 
+// Mark this capture as ODR-used if we are in a lambda
+// expression and the callee is UnresolvedMemberExpr.
+LambdaScopeInfo *CurLSI = getCurLambda();
+if (CurLSI && isa(Fn->IgnoreParens())) {
+  for (auto &Capture : CurLSI->Captures) {
+if (Capture.isThisCapture()) {
+  Capture.markUsed(/*IsODRUse=*/true);
+}
+  }
+}
+
 return CallExpr::Create(Context, Fn, ArgExprs, Context.DependentTy,
 VK_RValue, RParenLoc);
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367497 - [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Ziang Wan via cfe-commits]

Author: ziangwan725
Date: Wed Jul 31 17:16:43 2019
New Revision: 367497

URL: http://llvm.org/viewvc/llvm-project?rev=367497&view=rev
Log:
[Sema] Enable -Wimplicit-float-conversion for integral to floating point 
precision loss

Issue an warning when the code tries to do an implicit int -> float
conversion, where the float type ha a narrower significant than the
float type.

The new warning is controlled by flag -Wimplicit-int-float-conversion,
under -Wimplicit-float-conversion and -Wconversion. It is also silenced
when c++11 narrowing warning is issued.

Differential Revision: https://reviews.llvm.org/D64666

Added:
cfe/trunk/test/Sema/implicit-int-float-conversion.c
cfe/trunk/test/Sema/implicit-int-float-narrowing.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/Sema/conversion.c
cfe/trunk/test/Sema/ext_vector_casts.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=367497&r1=367496&r2=367497&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Wed Jul 31 17:16:43 2019
@@ -62,7 +62,8 @@ def BoolConversion : DiagGroup<"bool-con
 def IntConversion : DiagGroup<"int-conversion">;
 def EnumConversion : DiagGroup<"enum-conversion">;
 def ImplicitIntConversion : DiagGroup<"implicit-int-conversion">;
-def ImplicitFloatConversion : DiagGroup<"implicit-float-conversion">;
+def ImplicitIntFloatConversion : DiagGroup<"implicit-int-float-conversion">;
+def ImplicitFloatConversion : DiagGroup<"implicit-float-conversion", 
[ImplicitIntFloatConversion]>;
 def ImplicitFixedPointConversion : 
DiagGroup<"implicit-fixed-point-conversion">;
 
 def FloatOverflowConversion : DiagGroup<"float-overflow-conversion">;

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=367497&r1=367496&r2=367497&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Jul 31 17:16:43 
2019
@@ -3266,6 +3266,14 @@ def warn_impcast_float_integer : Warning
   "implicit conversion turns floating-point number into integer: %0 to %1">,
   InGroup, DefaultIgnore;
 
+// Implicit int -> float conversion precision loss warnings.
+def warn_impcast_integer_float_precision : Warning<
+  "implicit conversion from %0 to %1 may lose precision">,
+  InGroup, DefaultIgnore;
+def warn_impcast_integer_float_precision_constant : Warning<
+  "implicit conversion from %2 to %3 changes value from %0 to %1">,
+  InGroup;
+
 def warn_impcast_float_to_integer : Warning<
   "implicit conversion from %0 to %1 changes value from %2 to %3">,
   InGroup, DefaultIgnore;

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=367497&r1=367496&r2=367497&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Wed Jul 31 17:16:43 2019
@@ -10200,7 +10200,8 @@ static bool IsSameFloatAfterCast(const A
   IsSameFloatAfterCast(value.getComplexFloatImag(), Src, Tgt));
 }
 
-static void AnalyzeImplicitConversions(Sema &S, Expr *E, SourceLocation CC);
+static void AnalyzeImplicitConversions(Sema &S, Expr *E, SourceLocation CC,
+   bool IsListInit = false);
 
 static bool IsEnumConstOrFromMacro(Sema &S, Expr *E) {
   // Suppress cases where we are comparing against an enum constant.
@@ -11161,9 +11162,10 @@ static bool isObjCSignedCharBool(Sema &S
  S.getLangOpts().ObjC && S.NSAPIObj->isObjCBOOLType(Ty);
 }
 
-static void
-CheckImplicitConversion(Sema &S, Expr *E, QualType T, SourceLocation CC,
-bool *ICContext = nullptr) {
+static void CheckImplicitConversion(Sema &S, Expr *E, QualType T,
+SourceLocation CC,
+bool *ICContext = nullptr,
+bool IsListInit = false) {
   if (E->isTypeDependent() || E->isValueDependent()) return;
 
   const Type *Source = S.Context.getCanonicalType(E->getType()).getTypePtr();
@@ -11405,6 +11407,54 @@ CheckImplicitConversion(Sema &S, Expr *E
 }
   }
 
+  // If we are casting an integer type to a floating point type without
+  // initialization-list syntax, we might lose accuracy if the floating
+  // point type has a narrower significand than the integer type.
+  if (SourceBT && TargetBT && SourceBT->isIntegerType() &&

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Phabricator via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL367497: [Sema] Enable -Wimplicit-float-conversion for 
integral to floating point… (authored by ziangwan725, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D64666?vs=212015&id=212706#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666

Files:
  cfe/trunk/include/clang/Basic/DiagnosticGroups.td
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaChecking.cpp
  cfe/trunk/test/Sema/conversion.c
  cfe/trunk/test/Sema/ext_vector_casts.c
  cfe/trunk/test/Sema/implicit-int-float-conversion.c
  cfe/trunk/test/Sema/implicit-int-float-narrowing.cpp

Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3266,6 +3266,14 @@
   "implicit conversion turns floating-point number into integer: %0 to %1">,
   InGroup, DefaultIgnore;
 
+// Implicit int -> float conversion precision loss warnings.
+def warn_impcast_integer_float_precision : Warning<
+  "implicit conversion from %0 to %1 may lose precision">,
+  InGroup, DefaultIgnore;
+def warn_impcast_integer_float_precision_constant : Warning<
+  "implicit conversion from %2 to %3 changes value from %0 to %1">,
+  InGroup;
+
 def warn_impcast_float_to_integer : Warning<
   "implicit conversion from %0 to %1 changes value from %2 to %3">,
   InGroup, DefaultIgnore;
Index: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td
@@ -62,7 +62,8 @@
 def IntConversion : DiagGroup<"int-conversion">;
 def EnumConversion : DiagGroup<"enum-conversion">;
 def ImplicitIntConversion : DiagGroup<"implicit-int-conversion">;
-def ImplicitFloatConversion : DiagGroup<"implicit-float-conversion">;
+def ImplicitIntFloatConversion : DiagGroup<"implicit-int-float-conversion">;
+def ImplicitFloatConversion : DiagGroup<"implicit-float-conversion", [ImplicitIntFloatConversion]>;
 def ImplicitFixedPointConversion : DiagGroup<"implicit-fixed-point-conversion">;
 
 def FloatOverflowConversion : DiagGroup<"float-overflow-conversion">;
Index: cfe/trunk/test/Sema/implicit-int-float-narrowing.cpp
===
--- cfe/trunk/test/Sema/implicit-int-float-narrowing.cpp
+++ cfe/trunk/test/Sema/implicit-int-float-narrowing.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 %s -verify -Wno-conversion -Wno-c++11-narrowing -Wimplicit-int-float-conversion
+
+void testNoWarningOnNarrowing() {
+  // Test that we do not issue duplicated warnings for
+  // C++11 narrowing.
+  float a = {L}; // expected-no-diagnostics
+
+  long b = L;
+  float c = {b}; // expected-no-diagnostics
+}
Index: cfe/trunk/test/Sema/implicit-int-float-conversion.c
===
--- cfe/trunk/test/Sema/implicit-int-float-conversion.c
+++ cfe/trunk/test/Sema/implicit-int-float-conversion.c
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 %s -verify -Wno-conversion -Wimplicit-int-float-conversion
+
+long testReturn(long a, float b) {
+  return a + b; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
+
+void testAssignment() {
+  float f = 22;
+  double b = L;
+
+#ifndef __ILP32__
+  float ff = L;// expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+  float  = UL; // expected-warning {{implicit conversion from 'unsigned long' to 'float' changes value from  to 1312}}
+#else
+  float ff = L;// expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+  float  = UL; // expected-warning {{implicit conversion from 'unsigned long long' to 'float' changes value from  to 1312}}
+#endif
+
+  long l = L;
+  float fff = l; // expected-warning {{implicit conversion from 'long' to 'float' may lose precision}}
+}
+
+void testExpression() {
+  float a = 0.0f;
+
+#ifndef __ILP32__
+  float b = L + a; // expected-warning {{implicit conversion from 'long' to 'float' changes value from  to 1312}}
+#else
+  float b = L + a; // expected-warning {{implicit conversion from 'long long' to 'float' changes value from  to 1312}}
+#endif
+
+  float g =  + ;
+  float c =  + 2223; // expected-warning {{implicit conversion from 'int' to 'float'

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Ziang Wan via Phabricator via cfe-commits]

ziangwan added a comment.

I have committed this patch. I will stay diligent in case anything fails.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits