deleted #4970
Closed
deleted #4970
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…erop
In a previous commit I taught APINotes to treat extern-c context as a
toplevel file context, but this only makes sense when we are handling
the decls handled in the block like VarDecls, FunctionDecls,
ObjCInterfaceDecls, etc.
But when the decl being handled for APINote is an ObjCMethod inside of a
ObjCContainer then it is important to allow the subsequent code in the
Sema::ProcessAPINotes function to handle things.
This can be excercised by the following APINote:
```
---
Name: SomeModule
Classes:
- Name: NSSomeClass
SwiftName: SomeClass
Methods:
- Selector: 'didMoveToParentViewController:'
SwiftName: didMove(toParent:)
MethodKind: Instance
```
This commit is now just a test case due to another commit that has
already landed.
The current design allows that the object file contents could be mapped by one object file plugin and then used by another. Presumably the idea here was to avoid mapping the same file twice. This becomes an issue when one object file plugin wants to map the file differently from the others. For example, ObjectFileELF needs to map its memory as writable while others likeObjectFileMachO needs it to be mapped read-only. This patch prevents plugins from changing the buffer by passing them is by value rather than by reference. Differential revision: https://reviews.llvm.org/D122944 (cherry picked from commit c69307e)
in 78233d9 checks the apropos string to make sure the command was added, but in TOT the first letter of the short help is capitalized, whereas in this branch it isn't, so the test had to be modified for this branch.
[lldb] Prevent object file plugins from changing the data buffer
Currently, the LLVM/LLDB timers are visible in Instruments for all apps. The developer-visible "PointsOfInterest" category is reserved for runtime issues and developer-authored "important" logging. These logs are visible to developer almost always in Instruments The LLVM/LLDB timers do not belong there. Having these present in the system is noisy and confusing to developers. This patch moves them under a new "toolchain" category. rdar://91266582 Differential revision: https://reviews.llvm.org/D123149 (cherry picked from commit e9ec161)
The concrete class (DataBufferLLVM) is an implementation detail. (cherry picked from commit 2165c36)
DataEncoder was previously made to modify data within an existing buffer. As the code progressed, new clients started using DataEncoder to create binary data. In these cases the use of this class was possibly, but only if you knew exactly how large your buffer would be ahead of time. This patchs adds the ability for DataEncoder to own a buffer that can be dynamically resized as data is appended to the buffer. Change in this patch: - Allow a DataEncoder object to be created that owns a DataBufferHeap object that can dynamically grow as data is appended - Add new methods that start with "Append" to append data to the buffer and grow it as needed - Adds full testing of the API to assure modifications don't regress any functionality - Has two constructors: one that uses caller owned data and one that creates an object with object owned data - "Append" methods only work if the object owns it own data - Removes the ability to specify a shared memory buffer as no one was using this functionality. This allows us to switch to a case where the object owns its own data in a DataBufferHeap that can be resized as data is added "Put" methods work on both caller and object owned data. "Append" methods work on only object owned data where we can grow the buffer. These methods will return false if called on a DataEncoder object that has caller owned data. The main reason for these modifications is to be able to use the DateEncoder objects instead of llvm::gsym::FileWriter in https://reviews.llvm.org/D113789. This patch wants to add the ability to create symbol table caching to LLDB and the code needs to build binary caches and save them to disk. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D115073 (cherry picked from commit 244258e)
(cherry picked from commit 220854a)
Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 (cherry picked from commit fc54427)
Change the CreateMemoryInstance interface to take a WritableDataBuffer. Differential revision: https://reviews.llvm.org/D123073 (cherry picked from commit f2ea125)
Fixes error: reinterpret_cast from type ‘const uint8_t*’ {aka ‘const
unsigned char*’} to type ‘char*’ casts away qualifiers
(cherry picked from commit a722dea)
(cherry picked from commit c2f6460)
Fixes error: invalid conversion from ‘const uint8_t*’ {aka ‘const
unsigned char*’} to ‘uint8_t*’ {aka ‘unsigned char*’}
(cherry picked from commit ed9a14f)
(cherry picked from commit b7bf5a7)
(cherry picked from commit 470eb5c)
(cherry picked from commit 70984dd)
(cherry picked from commit cfe5d76)
…b6b72c64f5b40e73f Change the LLVM signpost category
The test added to TestContainerCommands.py cherry-picked
[lldb] Refactor DataBuffer so we can map files as read-only
Without the fix ivars with anonymous types can trigger errors like > error: 'TestClass::structIvar' from module 'Target' is not present in definition of 'TestClass' provided earlier > [...] > note: declaration of 'structIvar' does not match It happens because types of ivars from different modules are considered to be different. And it is caused by not merging anonymous `TagDecl` from different modules. To fix that I've changed `serialization::needsAnonymousDeclarationNumber` to handle anonymous `TagDecl` inside `ObjCInterfaceDecl`. But that's not sufficient as C code inside `ObjCInterfaceDecl` doesn't use interface decl as a decl context but switches to its parent (TranslationUnit in most cases). I'm changing that to make `ObjCContainerDecl` the lexical decl context but keeping the semantic decl context intact. Test "check-dup-decls-inside-objc.m" doesn't reflect a change in functionality but captures the existing behavior to prevent regressions. rdar://85563013 Differential Revision: https://reviews.llvm.org/D118525 (cherry picked from commit 29444f0)
[c++-interop] Teach APINotes to handle ObjCContainer items while in C++-Interop
…ebug variable. Otherwise, we may hoist a llvm.dbg.addr over another llvm.dbg.addr or llvm.dbg.value, changing observable debugging state. As an additional benefit, this finally lets me add straight line end to end lldb tests for async var and lets. This was the last thing stopping me from doing that.
… handrolling continue via a run cmd.
…to the current function from parent function when evaluating subexpressions. This occurs when the parent function does not have debug info (*). In swift async functions this is ok since we only need to be able to restore the ABI defined context register for the async context (r14)... so it is not necessary to match with a callsite parameter. (*) E.x.: On Linux async funclets called from a libswift_Concurrency.so that had its debug info stripped.
Swift uses the Clang Driver to detect default include paths for C++ interop. This will allow us to revert #4693 and have a smaller diff with upstream.
The usual strategy of TypeSystemSwiftTypeRef functions is to fallback to SwiftASTContext in case it fails, make GetBitSize follow that pattern. Also, always log that failure even in the case of types defined in the expression, as we've been recovering information for those types for a while now. rdar://96166383
[lldb] TSSTypeRef::GetBitSize fallback to SASTContext if runtime fails
…chO.h Certain SDKs transitively include mach/machine.h which defines constants that conflict with llvm/BinaryFormat/MachO.h. By ordering the includes we can avoid the conflict. rdar://96148553
[cxx-interop] Allow Swift to get a Clang Toolchain from the Driver
rdar://96166383 rdar://96166324
…ath from Clang" This trick is no longer needed, Swift switched to another way to retrieving the include paths. This reverts commit dd4e712.
…20211026 Revert "[cxx-interop] Allow Swift to extract libstdc++ installation path from Clang"
[lldb] Pass likely module names to reflection parsing machinery
[clang] Add deployment target env vars to features.json
…idation [lldb] Skip validation of CGPoint in TypeSystemSwiftTypeRef
Recognize async closures as being async, in `IsSwiftAsyncFunctionSymbol`. Like `static` functions, this requires peeling off a wrapper node to get to the `Function` node. rdar://94840584
|
ignore, mistake |
kastiglione
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.