Assuming origin/maain is a branch typo and is no longer being tracked, would you please delete the upstream one in https://github.com/llvm/llvm-project/branches?

Return resolved DWARF enums from lambda.

Sink assert using lambda

In D116480#3220066, @dblaikie wrote:

Perhaps the right thing to do then would be to sink the assertion back down in some way - either just duplicating it in the two places it's used or using a lambda, perhaps?

In D116480#3220038, @dblaikie wrote:

Could you add some details about where the assert came from/went to, link to the patch that made the change?

Fix test for windows

Thank you for the patch! It makes sense that the check functions depend on the corresponding language to be enabled.

Actually, I just thought of a possible limitation of using path-append when suffixing with something that isn't actually a path component. However, I cannot say how critical this limitation is.

Add ReadConfigFile test case for multiple <CFGDIR> in one arg.

Update ReadConfigFile test with additional <CFGDIR> expansion contexts (non-prefixed, non-suffixed, escaped in middle).

Update call parameters in ExpandResponseFilesDatabase::expand

Make <CFGDIR> constant at point of expansion. Use bool parameter to activate <CFGDIR> expansion.

Rebase, use the slightly more intuitive <CFGDIR> token to expand base paths.

Make expansion token a parameter of ExpandResponseFiles and limit use to readConfigFile. Elaborate manual entry further and add entry to release notes.

1. It it possible to limit the new syntax to config files only? It would avoid concerns of gcc compatibility.

bump, review requested

In D115604#3188392, @kadircet wrote:

IIUC, the new behavior being introduced by this patch is not the ability of having a way to refer to other files in a config/response file relative way, but rather extending that ability from only the options that start with @ to options that contain @ as a sub-string in any place.

Test coverage for more than one <@> per arg.

Fix ResponseFiles test for Windows.

Add entry to user manual explaining the <@> token.

It should be evaluated if <@> is a sufficiently unique token to not accidentally break existing users' response files. The use of shell operator characters would likely ensure this.

Thanks everyone for the comments. May I have somebody commit this for me?
--author="Jack Andersen <jackoalan@gmail.com>"

Rebase, Change TracksDebugUserValues comment per review request

I also do not have commit access yet. Would you mind committing this for me?
--author="Jack Andersen <jackoalan@gmail.com>"

I should also note that I tested this change on Windows and this does not interfere with package importing there. (LLVM_ENABLE_TERMINFO and LLVM_ENABLE_FFI are set false in LLVMConfig.cmake)

In D114327#3158666, @JDevlieghere wrote:

I'm assuming the logic to find the actual packages is the same

Yes, mostly existing code refactored into find modules.

Use LLDB's find module naming conventions and style.

Abandoning this for now. A more sensible approach to the use case has been discovered.

Fix clang-format issue

Clarify TracksDebugUserValues documenting comment.

• Rename DebugValuesAllocated -> TracksDebugUserValues
• Documenting comment for TracksDebugUserValues
• MIR key for TracksDebugUserValues
• TracksDebugUserValues tests for MachineVerifier
• LiveDebugValues test to ensure undefined debug uses delete DBG_VALUE instructions

In D112852#3146936, @MatzeB wrote:

That said I don't feel strongly about this. If others think this is benefitial then we can go ahead.

In D112852#3098095, @MatzeB wrote:

Before we weaken the verifier

The weakening conditions are now much more targeted to this specific case.

Specifically check for vregs without defs when suppressing verification errors.

Update comment

Rebase

ping

Thank you for the feedback! Would you mind committing this? --author="Jack Andersen <jackoalan@gmail.com>"

Abandoning this for now, since the solution would be completely rethinking how debug value uses are handled.

All, that makes much more sense. If performance is the objective, allowing the dangling use and relaxing the asserts might be the better option.

Fix patch format

Add unit test

Thank you for the feedback! Would you mind committing this? --author="Jack Andersen <jackoalan@gmail.com>"

Remove now-redundant MachineVerifier check. Also check debug instructions on uses only and non-debug instruction case.

Apply to all debug instructions according to MachineInstr::isDebugInstr

Add check to MachineVerifier. Remove explicit debug operand flag uses.

Not a problem, thank you for the quick turnaround :)

In D110659#3029327, @lhames wrote:

Thanks Jack. I'm not sure what LLVM's policy is with regards to --author

I do not have commit access, it'd be great if you'd do that. --author="Jack Andersen <jackoalan@gmail.com>"

Also curious if invariant debug register operands are applicable to other debug instructions (DBG_INSTR_REF, DBG_PHI, DBG_LABEL)

Shouldn't be too difficult to add the MachineVerifier check and remove the setIsDebug calls. Shall I also remove RegState::Debug in the context of DBG_VALUE builders?

Cover MachineOperand::ChangeToRegister with invariant. Add unit test to MachineInstrTest.cpp