Sorry, I was away during the holidays but just pushed the change.

Rebase

Add wstring_view test

Fix formatting type in release notes

Add release notes

Improve readability based on review commens

In D75649#1916265, @rriddle wrote:

In D75649#1916222, @mehdi_amini wrote:

using OpBuilder::create is much more idiomatic with the rest of the infra.

The builder APIs don't express clear ownership though, having a RAII type would be nice!
Could the OpBuilder::create always return an OwningOpRef<OpTy> ?

That doesn't really make sense to me, OpBuilder::create generally inserts the operation into a block. I'm not sure what ownership semantics you are assigning to it here. Am I missing something? OpBuilder::create isn't a static method.

Hi River, I have two (somewhat related) usecases for having a FuncOp without adding it to a module:

1. I would like to write an mlir::OwingFuncRef BuildFunc(...) function what takes some internal/domain specific input (e.g. IR from the front end) and returns the newly built function. I could just pass in the ModuleOp as an argument and add the FuncOp to it but returning an OwningFuncRef feels like a nicer API
2. My code what builds a FuncOp might fail (e.g. due to invalid input) and in that case I want to report an error without modifying the existing ModuleOp as adding a broken function to it would make the module op broken as well. My approach for it is to create an OwningFuncRef, use it to own the FuncOp during the building process (so in case of a failure it will correctly destroy it) and then in case of success I would move the FuncOp from the OwningFuncRef to the ModuleOp.

Add missing include

Fix code formatting

Re-try addressing review comments

Address review comments

Fix attribute accessor to not crash for null values

LGTM

I have no memory about the history/background of the OCaml plugin but no objection from my side.

LGTM. Thank you for removing it.

LGTM. Adding Ryan as a reviewer as he was the original implementer but I am not sure if his account (and the linked e-mail) is still active.

BTW this can also happen if we are missing some debug info.

I think it isn't an A/B locking issue. The problem is that 2 different thread (main thread and 1 of the DWARF indexer thread) want to lock the mutex at the same time.

In D39825#920739, @alexshap wrote:

@tberghammer, SymbolFileDWARF (the base class of SymbolFileDWARFDwo) calls Index()
"lazily" in may places, so indexing of dwo happens almost inevitably (at the moment)
(FindCompleteObjCDefinitionTypeForDIE is just one example).

I never tried debugging Objective-C using dwo but I am pretty sure this won't fix the issue you are seeing for FindCompleteObjCDefinitionTypeForDIE correctly because this way you will index the compile unit twice (once from the main object file and once from the dwo), then create 2 CompilerType for the 2 indexed version and will start hitting random issues in expression evaluation when clang will get confused by 2 declaration for the same type. If I am not mistaken then because of this, calling Index on a Dwo file is a pretty bad idea. Instead of trying to get it work we should change it to be an assert so people don't call it by accident.

How are you end up calling SymbolFileDWARFDwo::Index? If I remember correctly you are not supposed to index a dwo file directly because without the main object file you won't have all of the necessary information.

I verified that D39545 will be fixing the problem on the LLDB side (previously we had no proper scoped enum support in LLDB)

This change is needed to make LLDB compatible with D39239

Fix test failures

In D39239#911696, @CarlosAlbertoEnciso wrote:

Hi Tamas,

Thanks very much for your message.

In D39239#910797, @tberghammer wrote:

• Can you do a diff of the debug_info dump before and after your change? Understanding what have changed should give us a pretty good clue about the issue.

For this specific case, the debug_info is the same before and after my change, as the patch affects only unscoped enums.

2 fairly random ideas without looking into it too much:

• Can you do a diff of the debug_info dump before and after your change? Understanding what have changed should give us a pretty good clue about the issue.
• My first guess is that after your change we emit DW_TAG_enumeration_type for scoped enums (what seems to be the correct thing to do) instead of something else (not sure what) and you have to update https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp#L1512 to handle it correctly.

Hi Carlos,

Looks good. Thanks for fixing it.

Looks good, thanks for fixing it.

I don't really have an opinion if moving TaskPool to Host is a good or bad idea (haven't followed the recent layering efforts) but other then that looks good. I also tested it on Linux and it works fine.

Looks good

Hi Jason,

Note about testing: I haven't manage to come up with any good approach so far for testing because only fairly new version of dwp or llvm-dwp can generate the format I am expecting here so adding a new config for the existing test suite seems a bit infeasible and also it would increase the testing time by a non negligible time.

Hi Greg, can you take a look sometime? Thanks, Tamas

Add comment about the MIPS special case.

Thanks for fixing it

I checked LLDB and it doesn't have support for base address entries neither in .debug_loc nor in .debug_loc.dwo sections and it doesn't support reading .debug_loclists or .debug_loclists.dwo entries either. I will try to add support for them but it will require some refactoring so it will take some time.

Thanks for all of the data. Based on this I think you are using a preview version of android O what reports SDK 25 but the linker works the way an SDK 26 system linker would do.

Submitted as rL309554 to get the buildbot using ToT clang green again but if you have any comment then let me know and I will address it in a followup CL.

Hi David,

Improve error handling

Hi Nitesh,

I tried to compile the code snippet you mentioned but it doesn't put anything into the debug_types section. If I move the enum definition outside of the class then it produces debug_type section but LLDB fails back gracefully without any crash or error message. I also tried a few other code snippets and the debugging experience usually wasn't great (types of local variables were messed up) but I haven't manage to get LLDB crashing.

Can you file a bug about this issue so we can keep track of it? Also it would be nice to include a small test case in the bug (if you have one) what demonstrates the crash as so far I only managed to see missing type information without an actual LLDB crash.

This section have been already removed from Dwarf5 so I agree that we shouldn't spend too much time adding support for it. Do you know anybody hitting this issue? Do you know why they decided to use this flag?

Looks good with one possible question

Looks good

Looks good

I few high level comments after a quick read through.

Makes sense. Thank you for the explanation (I assumed homogeneous aggregate and vector are the same).