RE: [clang] 4821508 - Revert "DebugInfo: Fully integrate ctor type homing into 'limited' debug info"

Hi Dave, The original commit message included Also fix a bug I found along the way that was causing ctor type homing to kick in even when something could be vtable homed Is it reasonable to fix that without removing ctor homing in general? Or would that cause too much test churn, as you'r

RE: Call for an assistance pushing patch review forward

Hi Mateusz, I wouldn’t worry too much about the failed build. I took a peek and it looks like the failures are mostly in places very unrelated to your patch. If your own testing shows no problems, it’s very likely you’re fine. Regarding lack of response, this is unfortunately more common than

RE: [clang] af1d3e6 - Allow init_priority values <= 100 and > 65535 within system headers.

> -Original Message- > From: cfe-commits On Behalf Of Aaron > Ballman via cfe-commits > Sent: Wednesday, September 23, 2020 3:27 PM > To: cfe-commits@lists.llvm.org > Subject: [clang] af1d3e6 - Allow init_priority values <= 100 and > 65535 > within system headers. > > > Author: Aaron B

RE: [clang-tools-extra] 8e325cf - [clangd] Work around PS4 -fno-exceptions, easier than disabling tests?

> -Original Message- > From: cfe-commits On Behalf Of Sam > McCall via cfe-commits > Sent: Thursday, May 28, 2020 11:15 AM > To: cfe-commits@lists.llvm.org > Subject: [clang-tools-extra] 8e325cf - [clangd] Work around PS4 -fno- > exceptions, easier than disabling tests? > > > Author: S

RE: r321312 - [AST] Incorrectly qualified unscoped enumeration as template actual parameter.

r321457. Happy new year! --paulr > -Original Message- > From: Kim Gräsman [mailto:kim.gras...@gmail.com] > Sent: Tuesday, December 26, 2017 1:56 AM > To: Robinson, Paul > Cc: cfe-commits > Subject: Re: r321312 - [AST] Incorrectly qualified unscoped enumeration as > template actual paramet

RE: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

On the lldb-dev thread I thought this was a reasonable idea (DW_AT_linkage_name on types) but given the use-case, probably best to confine it to classes with vtables? If there's a broader use-case it wasn't clear from the other thread; there it was reported that LLDB really only uses the mangle

RE: [clang-tools-extra] r318287 - [clangd] Support returning a limited number of completion results.

Hi Sam, It looks like llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast has been failing a couple of clangd tests ever since this went in. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/13517 Please fix or revert ASAP when bots go red. Failures like this

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

(though perhaps we had some position that debugger tuning wouldn't ever be the only way to access functionality, only change defaults) That's correct. Tuning must unpack to other settings that can be set separately. That was very strong feedback from when we introduced the tuning concept. --p

RE: [PATCH] D36501: add flag to undo ABI change in r310401

Paul: is the PS4 toolchain's ABI based on that of a particular Clang release, or is it a branch from trunk at some point? Or something else? (And which release / revision?) I am reminded that there are two parts to the ABI, the C++ part and the platform part. PS4's C++ ABI is whatever Clang 3.2

RE: r296554 - [PS4] Set our default dialect to C++11. NFC for other targets.

Mehdi, again I invite you to discuss this on the cfe-dev thread rather than here. I have posted a reply there to bump it up, and any comments you have will be more visible and better serve the community over there. Thanks, --paulr From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com] Sent:

RE: r296554 - [PS4] Set our default dialect to C++11. NFC for other targets.

Probably better to debate this on the cfe-dev thread "Setting default dialect to C++11" than here. That said, it's far from the only target-dependent setting in the driver. There are things ranging from the default DWARF version to whether exceptions are on by default to whether Microsoft exten

RE: r293457 - Tidy up codegen modules test & make it x86 specific since it relies on Itanium name manglings

Okay as is, then. Thanks for the explanation. --paulr From: David Blaikie [mailto:dblai...@gmail.com] Sent: Monday, January 30, 2017 9:32 AM To: Robinson, Paul Cc: cfe-commits (cfe-commits@lists.llvm.org) Subject: Re: r293457 - Tidy up codegen modules test & make it x86 specific since it relies

RE: r293457 - Tidy up codegen modules test & make it x86 specific since it relies on Itanium name manglings

Use %itanium_abi_triple instead? > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > David Blaikie via cfe-commits > Sent: Sunday, January 29, 2017 9:34 PM > To: cfe-commits@lists.llvm.org > Subject: r293457 - Tidy up codegen modules test & m

RE: r292568 - [test] Remove an unwanted match for `UNSUPPORTED:`.

I'd call this a bug in lit; it shouldn't be matching partial tokens. --paulr > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Greg Parker via cfe-commits > Sent: Thursday, January 19, 2017 6:12 PM > To: cfe-commits@lists.llvm.org > Subject

RE: [PATCH] D28404: IRGen: Add optnone attribute on function during O0

(Re-add cfe-commits; otherwise same) > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Duncan P. N. Exon Smith via cfe-commits > Sent: Monday, January 09, 2017 4:10 PM > To: reviews+d28404+public+53e0f4655ef79...@reviews.llvm.org > Cc: nhae

RE: r284793 - Remove 24 instances of 'REQUIRES: shell'

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Reid Kleckner via cfe-commits > Sent: Thursday, October 20, 2016 4:12 PM > To: cfe-commits@lists.llvm.org > Subject: r284793 - Remove 24 instances of 'REQUIRES: shell' > > Author: rnk > Dat

RE: r284416 - Driver/Darwin: Set the DWARF version based on the deployment target.

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Adrian Prantl via cfe-commits > Sent: Monday, October 17, 2016 12:36 PM > To: cfe-commits@lists.llvm.org > Subject: r284416 - Driver/Darwin: Set the DWARF version based on the > deployment

RE: r284174 - Disable swiftcall test on windows: More brutal way to appease windows bots

Is there a bug to track this problem so it doesn't get lost? --paulr From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Reid Kleckner via cfe-commits Sent: Thursday, October 13, 2016 4:02 PM To: Arnold Schwaighofer Cc: cfe-commits Subject: Re: r284174 - Disable swiftcall t

RE: [PATCH] D24426: DebugInfo: Pass non-zero alignment to DIBuilder only if aligment was forced

I hadn't thought Clang wanted to be *quite* so knowledgeable about targets, and similarly not so tightly tied to byte-addressable targets. But if both of those things are actually okay, then it's fine to set the alignment value here to what would be passed through to DWARF. --paulr From: David

RE: [PATCH] D24426: DebugInfo: Pass non-zero alignment to DIBuilder only if aligment was forced

The text in the committee draft is different (e.g., the exhortation about non-default alignment is gone), with an example to the effect that a value of 8 means the entity's address is a multiple of 8 (not 2^8). So, alignment is conceived in terms of address bits, whatever those represent (not a

RE: r280057 - Combine two FileCheck patterns to prevent overzealous matching of .*

The case that failed on the build not was something like -o blah.o -x c++ -o system /.../llvm.org/... ... where the first line of the old pattern matched up to the .o in llvm.org, causing the second line to fail to match. That suggests the .* behavior is 'gree

RE: r280057 - Combine two FileCheck patterns to prevent overzealous matching of .*

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Richard Smith via cfe-commits > Sent: Monday, August 29, 2016 10:15 PM > To: cfe-commits@lists.llvm.org > Subject: r280057 - Combine two FileCheck patterns to prevent overzealous > matching

RE: r278710 - Replace an obsolete company name.

I had tried doing that in the Users.html page when I first added an entry there, and it caused problems. So, I'd rather not embed a unicode character directly into the file, and I'd rather use a semi-intelligible substitution name than some raw hex value. The intent is clearer. --paulr From:

RE: r276102 - [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Simon Pilgrim via cfe-commits > Sent: Wednesday, July 20, 2016 3:18 AM > To: cfe-commits@lists.llvm.org > Subject: r276102 - [X86][SSE] Reimplement SSE fp2si conversion intrinsics > instead

RE: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

> > I think we could emulate any pre-commit hook we like via GitHub > > WebHooks by having two repositories: llvm and llvm-staging (say). > > > > People push to llvm-staging, which notifies some LLVM server we own. > > That does basic sanity checks and pushes to llvm proper if passed. > > I think

RE: [PATCH] D22096: [OpenMP] Sema and parsing for 'target parallel for simd' pragma

> -Original Message- > From: Alexey Bataev [mailto:a.bat...@hotmail.com] > Sent: Thursday, July 14, 2016 7:51 PM > To: reviews+d22096+public+4c00789034d62...@reviews.llvm.org > Cc: cfe-commits@lists.llvm.org; kkw...@gmail.com; cber...@us.ibm.com; > sfan...@us.ibm.com; hfin...@anl.gov; acj

RE: r275040 - [CodeGen] Treat imported static local variables as declarations

A declaration that gets used within the CU generally does get a debug-info description. I think no DWARF-using target has dllimport (yet) so you are actually handling a new situation here. Being unable to find the entity in the dllimport-using CU is not a friendly debugging experience. --paulr

RE: r275040 - [CodeGen] Treat imported static local variables as declarations

I was asking for the debug info to describe the entity as a declaration, rather than a definition. Instead you eliminated the debug-info description entirely. These are pretty different things. --paulr From: David Majnemer [mailto:david.majne...@gmail.com] Sent: Monday, July 11, 2016 12:27 PM T

RE: r275040 - [CodeGen] Treat imported static local variables as declarations

It was not particularly obvious that by "static local variables" you actually meant "template static data members." Now I can tell that this is not addressing what I was asking about in the comment on r274986. --paulr From: David Majnemer [mailto:david.majne...@gmail.com] Sent: Monday, July 11,

RE: r275040 - [CodeGen] Treat imported static local variables as declarations

This changes the IR but not the debug-info metadata? --paulr > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > David Majnemer via cfe-commits > Sent: Sunday, July 10, 2016 9:28 PM > To: cfe-commits@lists.llvm.org > Subject: r275040 - [CodeG

RE: r274084 - Revert "[PS4] Tighten up a test (noticed in passing)"

With some digging I worked out at least part of the history. It's not that we care about PATH per se; the test is making sure that even if you don't have a linker in the package, there's still a file with the right name for clang to find in a place that it would (eventually) look. If you *do*

RE: r274246 - [codeview] Emit qualified display names if -gline-tables-only is on

The rationale is no different for DWARF than for CodeView, there's no other way to get the fully qualified name of an inlined function. Unless you want to connect this up to the existing DWARF hook for putting linkage names on inlined subprograms? The downside there is that linkage names are p

RE: r274084 - Revert "[PS4] Tighten up a test (noticed in passing)"

Okay, that is peculiar. But I can repro it. If I put either orbis-ld or orbis-ld.exe co-located with clang.exe, it builds a command line without the .exe suffix (but using the directory where clang.exe lives). I do think a bug report would have been appropriate, rather than just munging the t

RE: r274084 - Revert "[PS4] Tighten up a test (noticed in passing)"

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Sean Silva via cfe-commits > Sent: Tuesday, June 28, 2016 5:29 PM > To: cfe-commits@lists.llvm.org > Subject: r274084 - Revert "[PS4] Tighten up a test (noticed in passing)" > > Author: si

RE: RFC: Default language standard mode policy

What Warren said. We've been carrying the private patch for 4 years or so, and now that we're getting the test changes upstream it will be progressively less of a problem for us. (And thanks Sean for actually trying it on a couple of titles! You read my mind.) I also wanted to add that I agr

RE: [PATCH] D19567: PR21823: 'nodebug' attribute on global/static variables

About to be away for a week, but I will take this up (and the other one) when I get back. --paulr From: David Blaikie [mailto:dblai...@gmail.com] Sent: Tuesday, May 17, 2016 3:05 PM To: reviews+d19567+public+1ee0c82c0824b...@reviews.llvm.org; David Blaikie Cc: Robinson, Paul; Aaron Ballman; Adria

RE: [PATCH] D19754: Allow 'nodebug' on local variables

What you are describing is what testing literature refers to as criteria for equivalence classes. There is some level of judgment to that, yes. Yep yep, to be sure. I'm just generally trying to encourage the community behavior towards being both selective & thorough about testing. I have notice

RE: [PATCH] D19754: Allow 'nodebug' on local variables

This would be a great conversation to have at the social, sadly I will have to miss it this month. >> dblaikie wrote: >>> Doesn't look like the const case is any different from the non-const >>> case, is it? >> Given a white-box analysis of the compiler internals, you are correct; >> this is in co

RE: [PATCH] D19689: Add Subjects to NoDebugAttr [NFC]

Generally tests test something other than "this program doesn't crash" - should it test that we apply the attribute correctly? (either via ast dump, or checking the resulting DWARF doesn't have debug info on the relevant entity) Or is this not actually a new/separate codepath? In which case do w

RE: [PATCH] D19567: PR21823: 'nodebug' attribute on global/static variables

Huh. There are strange interactions here, which makes me even more nervous about testing fewer cases. As it happens, the test as written did not exercise all 3 modified paths. Because 'struct S2' had all its members marked with nodebug, none of the static-member references caused debug info for

RE: r266005 - Allow simultaneous safestack and stackprotector attributes.

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Evgeniy Stepanov via cfe-commits > Sent: Monday, April 11, 2016 3:28 PM > To: cfe-commits@lists.llvm.org > Subject: r266005 - Allow simultaneous safestack and stackprotector > attributes. >

RE: r265218 - [test] Don't use "UNSUPPORTED" in FileCheck prefixes

Is it worth teaching FileCheck about lit-defined keywords, and reject check-prefixes that end in one of them? Offhand that would be UNSUPPORTED, RUN, REQUIRES, XFAIL (I haven't actually gone to look at what lit knows). --paulr > -Original Message- > From: cfe-commits [mailto:cfe-commits-bo

RE: r262688 - [X86] Pass __m64 types via SSE registers for GCC compatibility

ented this one to our licensees. So, > > from our perspective, it's not a bug, it's a feature. :-) Describing > > it as a bug (at least for PS4) would be technically incorrect. > > --paulr > > > >> > >> On Fri, Mar 4, 2016 at 2:03 AM, Robinson

RE: r262688 - [X86] Pass __m64 types via SSE registers for GCC compatibility

would be technically incorrect. --paulr > > On Fri, Mar 4, 2016 at 2:03 AM, Robinson, Paul via cfe-commits > wrote: > >> To: cfe-commits@lists.llvm.org > >> Subject: r262688 - [X86] Pass __m64 types via SSE registers for GCC > >> compatibility > >>

RE: r262688 - [X86] Pass __m64 types via SSE registers for GCC compatibility

> To: cfe-commits@lists.llvm.org > Subject: r262688 - [X86] Pass __m64 types via SSE registers for GCC > compatibility > > Author: majnemer > Date: Thu Mar 3 23:26:16 2016 > New Revision: 262688 > > URL: http://llvm.org/viewvc/llvm-project?rev=262688&view=rev > Log: > [X86] Pass __m64 types via

RE: r250293 - Bring back r250262: PS4 toolchain

Nico asks: +def warn_drv_ps4_force_pic : Warning< + "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">, + InGroup; Should this use the existing UnusedCommandLineArgument instead of introducing a new group? Depends on what kinds of distinctions you want to make, when it comes to h

RE: r260334 - Get rid of CHECK-SAME-NOT in tests.

Well I'll be-- thanks! See post-commit comments, see below, tidying up just a bit. --paulr > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Justin Lebar via cfe-commits > Sent: Tuesday, February 09, 2016 4:38 PM > To: cfe-commits@lists.llv

RE: r259489 - Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend.

Maybe Basic would be a better home for the new header? Having CodeGen pull in something from Driver seems weird and unprecedented. Thanks, --paulr > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Benjamin Kramer via cfe-commits > Sent: Tue

RE: [PATCH] D16754: Bug 15785 - OpenCL errors using vector/scalar conditionals and short integer types

> Hi Anton, > > Okey, nevermore. > But what to do with a bug which needs simply be closed (NABs)? > I believe they also need a review/approval. > > Igor Bugs do not have such a strict process, compared to patches. If you don't feel confident in closing the bug directly, you can

RE: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Duncan P. N. Exon Smith via cfe-commits > Sent: Monday, January 11, 2016 4:21 PM > To: Rafael Espíndola > Cc: Marshall Clow; CFE Commits > Subject: Re: [libcxx] r196411 - Give all members of

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: | And at runtime, on some targets, we use this: | | https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c | | ... which gives a NaN in this case. I copied that func

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

| Types are a bit more vague (as to whether omitting unreferenced types is supported by the standard) DWARF 4 just says "Structure, union, and class types are represented by debugging information entries ...". There's some expansion of the "permissive" discussion in the works for DWARF 5. In e

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

Maybe we are being too pedantic about the names. I'll have to go back and look in detail at why we decided to do that. In any case, arguably 5.5.8 (Class Template Instantiations) 1 only applies to definitions of a type, not declarations. ("Each formal parameterized type declaration appearing i

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

Actually no, we prefer to have the original typedef names in the instantiation name, for source fidelity. "Name as it is in the source" or something reasonably close. Unwrapping typedefs is going too far. Re. "looseness" of the DWARF spec, it is not so loose as you like to think. Attributes

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be surprising if we used the typedef (or otherwise non-canonical) name in the class name): Finally getting back to this….. Ha. We don't unwrap the typedefs ("name as it is in the source"), while the upstream compiler does. Providi

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

| And at runtime, on some targets, we use this: | | https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c | | ... which gives a NaN in this case. I copied that function into a test program on Ubuntu, built with gcc, and it gives me +Infinity (0x7f80) not NaN (0x7fc0

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Okay, I'll bite: so what *does* UINT128_MAX actually convert to? From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Richard Smith via cfe-commits Sent: Tuesday, December 08, 2015 10:52 AM To: Joerg Sonnenberger; cfe-commits Subject: Re: r254574 - PR17381: Treat undefined

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Treat undefined behavior during expression evaluation as an unmodeled I've amended this change to permit constant-foldable UB in C variable initializers again in r254992. On Mon, Dec 7, 2015 at 6:45 PM, Robinson, Paul via cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote: Two

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Two more questions: (1) Commit message implied this is only for C, but I see it with C++11 (but not C++03). $ cat t.cpp enum { foo = 123456 * 234567 }; $ clang -c t.cpp -std=c++03 $ clang -c t.cpp -std=c++11 t.cpp:1:14: error: expression is not an integral constant expression (2) Shouldn't

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

Explicitly cc: cfe-commits *again*…. | C11 6.3.1.5/1: "If the value being converted is outside the range of values that can be represented, the behavior is undefined." I think 5.2.4.2.2/5 says if infinities are representable, there are no values "outside" the floating-point ra

RE: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

Resending because I forgot to explicitly CC the list AGAIN. :-P > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Simon Pilgrim via cfe-commits > Sent: Sunday, November 29, 2015 12:23 PM > To: cfe-commits@lists.llvm.org > Subject: r254262 -

RE: r252834 - Provide a frontend based error for always_inline functions that require

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Eric Christopher via cfe-commits > Sent: Wednesday, November 11, 2015 4:44 PM > To: cfe-commits@lists.llvm.org > Subject: r252834 - Provide a frontend based error for always_inline > functi

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

| when/where/why are types acquired from the mangled names of ELF symbols, rather than from corresponding DWARF? Pete, can you help me out here? David seems to want an ironclad case for not being able to do something any other way, before he will let me put the template type parameters on the

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

| Why is matching by name insufficient/not correct? I'm told we look at the mangled names in the ELF symbol table, demangle them, and look in the DWARF for the corresponding types. Now, the mangled name (for predefined types in particular) provides a type description, not the name-as-emitted-by

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

| What was your primary motivation? A similar concern to PR20455 from our own debugger. It much helps matching up the forward declaration and definition to have the parameters properly specified. | maybe it's possible to remangle the template using just the string name I have no idea what you'r

RE: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

Would citing PR20455 help? It wasn't actually my primary motivation but it's not too far off. Having the template parameters there lets you know what's going on in the DWARF, without having to fetch and parse the name string of every struct you come across. Actually I'm not sure parsing the n

RE: r250173 - Always pass a -dwarf-version argument to integrated as.

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Douglas Katzman via cfe-commits > Sent: Tuesday, October 13, 2015 9:23 AM > To: cfe-commits@lists.llvm.org > Subject: r250173 - Always pass a -dwarf-version argument to integrated as. > >

RE: [PATCH] D12624: Top-level anonymous namespaces are missing import DW_TAG_imported_module and nested anonymous namespaces are not

This seems pretty fine-grained for a CodeGenOpt (not that I've looked there, perhaps there are examples of similarly fine grained things already there?)- I'm curious to understand the preference towards that rather than perhaps the more general "Debugger tuning" sort of thing Paul's implemented/