Re: [lldb-dev] [cfe-dev] [Call for Volunteers] Bug triaging
Hi Zach, Thanks for putting the data in a spreadsheet - that’s easier to navigate. And thanks for re-raising the question whether we have the right components in bugzilla. As I think this could be an area for lots of different opinions, without any near-perfect solution, it has the potential to be a discussion that drags on for a long time. I thought half of all bugs not getting triaged was a serious enough problem to try and tackle first (with this mail thread) before aiming to improve the component breakdown in bugzilla. I think that setting default-cc lists on the components we have currently is largely orthogonal to reducing/merging components, as we can always merge default-cc lists when we merge components. On actually coming up with a refined list of components: I think we’ll need to define/agree first on what guiding principles we follow when deciding something is worthwhile to be a separate component. Over the past few weeks I’ve heard a number of different options, ranging over: * Just make a component for every sub-directory in the source code. * Just make a component for every library that gets build in the LLVM build. * Make components so that each component has a significant enough number of issues raised against it (I’m trying to paraphrase what you’re proposing below). In my mind, the guiding principle should be: * Components should reflect an area of expertise, so that each component can have a set of recognised people that can triage and/or fix bugs against that component. If we’d follow that principle, I think we should not merge all components with less than 10 bugs reported into an “Other” component. I do agree that some merging could still probably be done. E.g. maybe all the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into a single component. So in summary: * I don’t think we need to delay assigning volunteers-for-triaging/default-cc lists to components. If we merge components later on, we can merge cc lists, or asks the volunteers for the relevant components If they want to remain on the default-cc list for the merged component. * My opinion is the we should define components based on areas of expertise. Thanks, Kristof On 8 Nov 2018, at 20:39, Zachary Turner mailto:ztur...@google.com>> wrote: Just so I'm clear, are we going to attempt to clean up and/or merge the components? If we are, it makes sense to do that before we start putting ourselves as default CC's on the various components since they will just change. If not, it would be nice to get some clarification on that now. I've put the above list into a spreadsheet so people can sort / filter it as they see fit. The link is here: https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0 I think a good starting point would be to get rid of any component with less than 10 bugs reported so far this year and merge them all into an "Other" component. On Thu, Nov 8, 2018 at 8:11 AM Kristof Beyls via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote: Hi, Yesterday, I’ve landed a description for how reported bugs should be flowing through the various stages of a bug’s life (triage, fixing, closing, …) at http://llvm.org/docs/BugLifeCycle.html. Thanks for the many many people who provided ideas and feedback for this! With there now being a description of what is expected during bug triaging (http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for more volunteers to actually do the bug triaging. About half of all raised bugs currently don’t seem to get triaged. The idea is to have one or more volunteers for each of the well over 100 different product/component combinations we have in bugzilla. If you volunteer to help with triaging bugs against a specific component, we’ll add you to the default cc list for that component, so that when a new bug is raised against that component, you’ll get notified automatically through email. For components with few reported bugs, a single triager may suffice. For the high-traffic components, we’ll probably need multiple volunteers. I’ve provided the list of product/components below that had bugs reported against in 2018, together with how many bugs were reported against them this year so far, as an indication for which components may need more volunteers. I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs” components as those tend to be components people file bugs against if they don’t have a clue which part of clang/llvm is causing the issue they’re seeing. I believe that you don’t need to be an expert to be able to triage most of those bugs. If you want to learn more about llvm, volunteering to triage those bugs may be an interesting way to learn a lot more yourself. How can you get added to the default cc list/volunteer? * Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get yourself added to the
Re: [lldb-dev] [cfe-dev] [llvm-dev] Updates on SVN to GitHub migration
Correct. One important part of the migration is the ability to keep the various CIs and other integrations intact via switching to svn-from-git bridge: https://help.github.com/articles/support-for-subversion-clients/ Otherwise the things might be even more complicated for downstream users. On Fri, Nov 9, 2018 at 10:56 AM Dean Michael Berris wrote: > > I think Anton is referring to the SVN bridge -- where Git repositories > can be accessed through the Subversion API/protocol. > On Fri, Nov 9, 2018 at 6:27 PM Jean-Daniel via cfe-dev > wrote: > > > > Isn’t the checkout a local operation that should not involved GitHub ? Did > > you mean the clone operation ? > > > > And about sparse-checkout, I though they require a full clone of the > > repository anyway. Is there a way to do a partial clone only ? > > > > Note: If you don’t need the whole history local, you may perform a swallow > > clone (using —depth 1). > > > > Le 9 nov. 2018 à 01:02, Anton Korobeynikov via llvm-dev > > a écrit : > > > > No idea, the checkout just timed out. I tried to play with sparse > > checkouts, etc. and my current hypothesis that the large number of > > revisions makes it unhappy. > > On Fri, Nov 9, 2018 at 2:39 AM James Y Knight wrote: > > > > > > It'd be nice to know what about our repository is breaking it. Do they have > > any idea what that is? > > > > For example -- I think that we probably will want to archive+discard many > > of the random branches and tags currently in the repository. If the large > > number of branches and tags is breaking it, then maybe it just starts > > working after we do so. > > > > On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov > > wrote: > > > > > > Some status update wrt GitHub SVN bridge. > > > > It does not work for any non-trivial (= LLVM) repo. I filled the issue > > there, however, there is no ETA when it will be fixed. Even worse, > > there are no promises that the issue will be addressed at all. Though > > they are aware that this is the issue for us. > > On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev > > wrote: > > > > > > What's the status here? > > > > Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated > > with the current status of things? > > > > And once things are usable, probably update > > https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo > > as well. > > > > On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev > > wrote: > > > > > > On 2018-10-24 08:25, Whisperity via cfe-dev wrote: > > > > They are not shown in the project graph, but if you open the "branch" > > drop down it has a tab named 'Tags'. > > > > > > It shows some tags there, but not all of them. But clicking "releases" > > then "Tags" will show this page [1], which seems to include all of them. > > > > [1] https://github.com/llvm-git-prototype/llvm/tags > > > > -- > > /Jacob Carlborg > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > > ___ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > > > > -- > > With best regards, Anton Korobeynikov > > Department of Statistical Modelling, Saint Petersburg State University > > > > > > > > > > -- > > With best regards, Anton Korobeynikov > > Department of Statistical Modelling, Saint Petersburg State University > > ___ > > LLVM Developers mailing list > > llvm-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > ___ > > cfe-dev mailing list > > cfe-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > -- > Dean -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Call for Volunteers] Bug triaging
To elaborate, I didn't mean to group all components with less than 10 bugs into one massive component. Rather, to do it separately for each subcomponent. Grouping by expertise is fine, but I would argue that a component with 2 or 3 bugs filed per year is not a very useful component. There has to be some kind of bar for having a component otherwise you end up in the situation we have now. If you apply this algorithm to the existing set of components, you end up with something like this: Clang: * New Bugs * C++ * Frontend * Formatter * LLVM Codegen * Static Analyzer * Driver * Modules * libclang * Other clang-tools * clang-tidy * Other compiler-rt * All Bugs Documentation * All Bugs libc++ * All Bugs libraries * Backend:X86 * Scalar Optimizations * Common Code Generator Code * Backend:AMDGPU * Loop Optimizer * Backend:WebAssembly * Backend:ARM * DebugInfo * Backend:AArch64 * MC * GlobalISel * Core LLVM classes * Global Analyses * Interprocedural Optimizations * Support Libraries * Backend:PowerPC * Linker * Transformation Utilities * Other lld * ELF * COFF * Other lldb * All Bugs LNT * All Bugs new-bugs * All Bugs OpenMP * Clang Compiler Support * Runtime Support Packaging * All Bugs Phabricator * All Bugs Polly * All Bugs Runtime Libraries * libprofile Test Suite * All Bugs tools * All Bugs Website * All Bugs XRay * All Bugs I don't think it's helpful to have what essentially amounts to lots of dead components, because it causes confusion for bug reporters as well as triagers. I also don't think the above split is radically different than what is already there, and for the most part, it still *is* organized by expertise. It also means you need to find less volunteers to add themselves to the cc list for various components. Instead of needing to find a separate volunteer for Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode Writer, and MCJIT, each of which has only 1 bug each (so in each case you're looking for a needle in a haystack to find the right person and get them to volunteer), you only need to find 1 for all of them, and there's a good chance that person will be at least somewhat familiar with backends in general and so know who the right person to talk to is in each case. Anyway, just my thoughts. On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls wrote: > Hi Zach, > > Thanks for putting the data in a spreadsheet - that’s easier to navigate. > > And thanks for re-raising the question whether we have the right > components in bugzilla. > As I think this could be an area for lots of different opinions, without > any near-perfect solution, it has the potential to be a discussion that > drags on for a long time. > I thought half of all bugs not getting triaged was a serious enough > problem to try and tackle first (with this mail thread) before aiming to > improve the component breakdown in bugzilla. > I think that setting default-cc lists on the components we have currently > is largely orthogonal to reducing/merging components, as we can always > merge default-cc lists when we merge components. > > > On actually coming up with a refined list of components: I think we’ll > need to define/agree first on what guiding principles we follow when > deciding something is worthwhile to be a separate component. > Over the past few weeks I’ve heard a number of different options, ranging > over: > > >- Just make a component for every sub-directory in the source code. >- Just make a component for every library that gets build in the LLVM >build. >- Make components so that each component has a significant enough >number of issues raised against it (I’m trying to paraphrase what you’re >proposing below). > > > In my mind, the guiding principle should be: > >- Components should reflect an area of expertise, so that each >component can have a set of recognised people that can triage and/or fix >bugs against that component. > > > If we’d follow that principle, I think we should not merge all components > with less than 10 bugs reported into an “Other” component. > I do agree that some merging could still probably be done. E.g. maybe all > the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be > merged into a single component. > > So in summary: > >- I don’t think we need to delay assigning >volunteers-for-triaging/default-cc lists to components. If we merge >components later on, we can merge cc lists, or asks the volunteers for the >relevant components If they want to remain on the default-cc list for the >merged component. >- My opinion is the we should define components based on areas of >expertise. > > > Thanks, > > Kristof > > On 8 Nov 2018, at 20:39, Zachary Turner wrote: > > Just so I'm clear, are we going to attempt to clean up and/or merge the > components? If we are, it makes sense to do that before we start putting > ourselves as default CC's on the various components since they will just > change. If not,
[lldb-dev] [CMake] LLDB framework / shared library
Hello Alex, hello Pavel I spent some time creating/streamlining our CMake infrastructure downstream of LLDB and learned a few things about bundles, versions, code-signing etc. (mostly on the Darwin side of things). I am currently sorting out what can be upstreamed and prepare reviews. Some work is still todo for the LLDB shared library/framework (for simplicity I will call it LLDB.framework). It would be great to know, if you have concerns or comments on the following points: (1) The liblldb target builds the actual LLDB.framework, while the lldb-framework target adds headers, symlinks, etc. What is the reason for this separation? Can I merge that into one target with post-build steps? (2) In previous reviews there was an effort to centralize the code for building LLDB.framework, which makes sense to me. With the current LLDBFramework.cmake approach, however, it’s spread over at least 3 different files (lldb/CMakeLists.txt for init and lldb/source/API/CMakeLists.txt for actual definition). In a similar case downstream, I did all that in a single CMakeLists.txt in the source folder. While I see that LLDBFramework affects the whole project, I don’t see why we need a separate LLDBFramework.cmake (BTW upstream it’s included only once). Do you think I can move things to lldb/source/API/CMakeLists.txt where possible? (3) Currently the build directory for LLDB.framework is determined from LLDB_FRAMEWORK_INSTALL_DIR, which I think is a little confusing. Can I clean this up? (e.g. having a LLDB_FRAMEWORK_BUILD_DIR) (4) With Xcode, executables are emitted in bin and copied to LLDB.framework where necessary. CMake emits them into LLDB.framework directly and creates symlinks to bin. With LLVM_EXTERNALIZE_DEBUGINFO on Darwin, this has the effect, that by default their dSYMs will end up in LLDB.framework. Thus, I would prefer the Xcode behaviour here. (5) Couldn’t (4) also simplify the INCLUDE_IN_SUITE logic? I would consider it to be LLDB.framework’s responsibility to set dependencies and adjust RPATHs for all required artefacts. The tools wouldn’t need to care about that (though, they could still check LLDB_BUILD_FRAMEWORK). The RPATH-login for case ARG_INCLUDE_IN_SUITE && LLDB_BUILD_FRAMEWORK is quite complicated though and I wonder if there are strong reasons not to do that. What do you think? (6) Just out of interest: why is LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7? Best Stefan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Call for Volunteers] Bug triaging
Hi Zach, Thanks for elaborating. I like your proposal. I agree it still groups per area of expertise. And it makes the set of components we have easier to manage. Before making changes though I hope to hear opinions from others on this. What do others think? Thanks, Kristof On 9 Nov 2018, at 18:05, Zachary Turner mailto:ztur...@google.com>> wrote: To elaborate, I didn't mean to group all components with less than 10 bugs into one massive component. Rather, to do it separately for each subcomponent. Grouping by expertise is fine, but I would argue that a component with 2 or 3 bugs filed per year is not a very useful component. There has to be some kind of bar for having a component otherwise you end up in the situation we have now. If you apply this algorithm to the existing set of components, you end up with something like this: Clang: * New Bugs * C++ * Frontend * Formatter * LLVM Codegen * Static Analyzer * Driver * Modules * libclang * Other clang-tools * clang-tidy * Other compiler-rt * All Bugs Documentation * All Bugs libc++ * All Bugs libraries * Backend:X86 * Scalar Optimizations * Common Code Generator Code * Backend:AMDGPU * Loop Optimizer * Backend:WebAssembly * Backend:ARM * DebugInfo * Backend:AArch64 * MC * GlobalISel * Core LLVM classes * Global Analyses * Interprocedural Optimizations * Support Libraries * Backend:PowerPC * Linker * Transformation Utilities * Other lld * ELF * COFF * Other lldb * All Bugs LNT * All Bugs new-bugs * All Bugs OpenMP * Clang Compiler Support * Runtime Support Packaging * All Bugs Phabricator * All Bugs Polly * All Bugs Runtime Libraries * libprofile Test Suite * All Bugs tools * All Bugs Website * All Bugs XRay * All Bugs I don't think it's helpful to have what essentially amounts to lots of dead components, because it causes confusion for bug reporters as well as triagers. I also don't think the above split is radically different than what is already there, and for the most part, it still *is* organized by expertise. It also means you need to find less volunteers to add themselves to the cc list for various components. Instead of needing to find a separate volunteer for Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode Writer, and MCJIT, each of which has only 1 bug each (so in each case you're looking for a needle in a haystack to find the right person and get them to volunteer), you only need to find 1 for all of them, and there's a good chance that person will be at least somewhat familiar with backends in general and so know who the right person to talk to is in each case. Anyway, just my thoughts. On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls mailto:kristof.be...@arm.com>> wrote: Hi Zach, Thanks for putting the data in a spreadsheet - that’s easier to navigate. And thanks for re-raising the question whether we have the right components in bugzilla. As I think this could be an area for lots of different opinions, without any near-perfect solution, it has the potential to be a discussion that drags on for a long time. I thought half of all bugs not getting triaged was a serious enough problem to try and tackle first (with this mail thread) before aiming to improve the component breakdown in bugzilla. I think that setting default-cc lists on the components we have currently is largely orthogonal to reducing/merging components, as we can always merge default-cc lists when we merge components. On actually coming up with a refined list of components: I think we’ll need to define/agree first on what guiding principles we follow when deciding something is worthwhile to be a separate component. Over the past few weeks I’ve heard a number of different options, ranging over: * Just make a component for every sub-directory in the source code. * Just make a component for every library that gets build in the LLVM build. * Make components so that each component has a significant enough number of issues raised against it (I’m trying to paraphrase what you’re proposing below). In my mind, the guiding principle should be: * Components should reflect an area of expertise, so that each component can have a set of recognised people that can triage and/or fix bugs against that component. If we’d follow that principle, I think we should not merge all components with less than 10 bugs reported into an “Other” component. I do agree that some merging could still probably be done. E.g. maybe all the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into a single component. So in summary: * I don’t think we need to delay assigning volunteers-for-triaging/default-cc lists to components. If we merge components later on, we can merge cc lists, or asks the volunteers for the relevant components If they want to remain on the default-cc list for the merged component. * My opinion is the we should define components based on areas of expertise. Thanks, Kristof On
Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging
I had considered a libraries/Backends:Other as well that would be separate from libraries/Other On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff wrote: > I wonder if backends are a special case to the heuristic of "let's not > make a bug component for code components that are too small". LLVM is > factored to cleanly separate backend code, to the point where it's the one > thing you can leave out at compile time; this can disincentivize people to > care about bugs in backends that they don't use (and conversely backends > seem like the most common/best supported out-of-tree use case). There's > obviously a lot of variance in how actively-developed the backends are and > how many people care about them, but it seems like if we care enough to > have the code in-tree then maybe we care enough to have a bug component too. > > On Fri, Nov 9, 2018 at 10:45 AM Kristof Beyls via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> Hi Zach, >> >> Thanks for elaborating. >> I like your proposal. I agree it still groups per area of expertise. And >> it makes the set of components we have easier to manage. >> Before making changes though I hope to hear opinions from others on this. >> What do others think? >> >> Thanks, >> >> Kristof >> >> >> On 9 Nov 2018, at 18:05, Zachary Turner wrote: >> >> To elaborate, I didn't mean to group all components with less than 10 >> bugs into one massive component. Rather, to do it separately for each >> subcomponent. Grouping by expertise is fine, but I would argue that a >> component with 2 or 3 bugs filed per year is not a very useful component. >> There has to be some kind of bar for having a component otherwise you end >> up in the situation we have now. >> >> If you apply this algorithm to the existing set of components, you end up >> with something like this: >> >> Clang: >> * New Bugs >> * C++ >> * Frontend >> * Formatter >> * LLVM Codegen >> * Static Analyzer >> * Driver >> * Modules >> * libclang >> * Other >> >> clang-tools >> * clang-tidy >> * Other >> >> compiler-rt >> * All Bugs >> >> Documentation >> * All Bugs >> >> libc++ >> * All Bugs >> >> libraries >> * Backend:X86 >> * Scalar Optimizations >> * Common Code Generator Code >> * Backend:AMDGPU >> * Loop Optimizer >> * Backend:WebAssembly >> * Backend:ARM >> * DebugInfo >> * Backend:AArch64 >> * MC >> * GlobalISel >> * Core LLVM classes >> * Global Analyses >> * Interprocedural Optimizations >> * Support Libraries >> * Backend:PowerPC >> * Linker >> * Transformation Utilities >> * Other >> >> lld >> * ELF >> * COFF >> * Other >> >> lldb >> * All Bugs >> >> LNT >> * All Bugs >> >> new-bugs >> * All Bugs >> >> OpenMP >> * Clang Compiler Support >> * Runtime Support >> >> Packaging >> * All Bugs >> >> Phabricator >> * All Bugs >> >> Polly >> * All Bugs >> >> Runtime Libraries >> * libprofile >> >> Test Suite >> * All Bugs >> >> tools >> * All Bugs >> >> Website >> * All Bugs >> >> XRay >> * All Bugs >> >> I don't think it's helpful to have what essentially amounts to lots of >> dead components, because it causes confusion for bug reporters as well as >> triagers. I also don't think the above split is radically different than >> what is already there, and for the most part, it still *is* organized by >> expertise. It also means you need to find less volunteers to add >> themselves to the cc list for various components. Instead of needing to >> find a separate volunteer for Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode >> Writer, and MCJIT, each of which has only 1 bug each (so in each case >> you're looking for a needle in a haystack to find the right person and get >> them to volunteer), you only need to find 1 for all of them, and there's a >> good chance that person will be at least somewhat familiar with backends in >> general and so know who the right person to talk to is in each case. >> >> Anyway, just my thoughts. >> >> On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls >> wrote: >> >>> Hi Zach, >>> >>> Thanks for putting the data in a spreadsheet - that’s easier to navigate. >>> >>> And thanks for re-raising the question whether we have the right >>> components in bugzilla. >>> As I think this could be an area for lots of different opinions, without >>> any near-perfect solution, it has the potential to be a discussion that >>> drags on for a long time. >>> I thought half of all bugs not getting triaged was a serious enough >>> problem to try and tackle first (with this mail thread) before aiming to >>> improve the component breakdown in bugzilla. >>> I think that setting default-cc lists on the components we have >>> currently is largely orthogonal to reducing/merging components, as we can >>> always merge default-cc lists when we merge components. >>> >>> >>> On actually coming up with a refined list of components: I think we’ll >>> need to define/agree first on what guiding principles we follow when >>> deciding something is worthwhile to be a separate component. >>> Over the past few weeks I’ve heard a number o
Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging
I also think that backends are a special case, and each should have its own component. Also a code owner, which I think is already the case; and just like ensuring patches get reviewed, a backend code owner should ensure there is a triager. It makes the list of components a bit longer, but adds no confusion to anyone trying to file a bug. Actually I'd say "libraries" as a higher-level component is more confusing, as a newcomer essentially never has to deal with LLVM libraries as a concept. --paulr From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary Turner via lldb-dev Sent: Friday, November 09, 2018 2:35 PM To: Derek Schuff Cc: llvm-dev; Kristof Beyls; nd; Clang Dev; LLDB Dev Subject: Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging I had considered a libraries/Backends:Other as well that would be separate from libraries/Other On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff mailto:dsch...@google.com>> wrote: I wonder if backends are a special case to the heuristic of "let's not make a bug component for code components that are too small". LLVM is factored to cleanly separate backend code, to the point where it's the one thing you can leave out at compile time; this can disincentivize people to care about bugs in backends that they don't use (and conversely backends seem like the most common/best supported out-of-tree use case). There's obviously a lot of variance in how actively-developed the backends are and how many people care about them, but it seems like if we care enough to have the code in-tree then maybe we care enough to have a bug component too. On Fri, Nov 9, 2018 at 10:45 AM Kristof Beyls via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: Hi Zach, Thanks for elaborating. I like your proposal. I agree it still groups per area of expertise. And it makes the set of components we have easier to manage. Before making changes though I hope to hear opinions from others on this. What do others think? Thanks, Kristof On 9 Nov 2018, at 18:05, Zachary Turner mailto:ztur...@google.com>> wrote: To elaborate, I didn't mean to group all components with less than 10 bugs into one massive component. Rather, to do it separately for each subcomponent. Grouping by expertise is fine, but I would argue that a component with 2 or 3 bugs filed per year is not a very useful component. There has to be some kind of bar for having a component otherwise you end up in the situation we have now. If you apply this algorithm to the existing set of components, you end up with something like this: Clang: * New Bugs * C++ * Frontend * Formatter * LLVM Codegen * Static Analyzer * Driver * Modules * libclang * Other clang-tools * clang-tidy * Other compiler-rt * All Bugs Documentation * All Bugs libc++ * All Bugs libraries * Backend:X86 * Scalar Optimizations * Common Code Generator Code * Backend:AMDGPU * Loop Optimizer * Backend:WebAssembly * Backend:ARM * DebugInfo * Backend:AArch64 * MC * GlobalISel * Core LLVM classes * Global Analyses * Interprocedural Optimizations * Support Libraries * Backend:PowerPC * Linker * Transformation Utilities * Other lld * ELF * COFF * Other lldb * All Bugs LNT * All Bugs new-bugs * All Bugs OpenMP * Clang Compiler Support * Runtime Support Packaging * All Bugs Phabricator * All Bugs Polly * All Bugs Runtime Libraries * libprofile Test Suite * All Bugs tools * All Bugs Website * All Bugs XRay * All Bugs I don't think it's helpful to have what essentially amounts to lots of dead components, because it causes confusion for bug reporters as well as triagers. I also don't think the above split is radically different than what is already there, and for the most part, it still *is* organized by expertise. It also means you need to find less volunteers to add themselves to the cc list for various components. Instead of needing to find a separate volunteer for Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode Writer, and MCJIT, each of which has only 1 bug each (so in each case you're looking for a needle in a haystack to find the right person and get them to volunteer), you only need to find 1 for all of them, and there's a good chance that person will be at least somewhat familiar with backends in general and so know who the right person to talk to is in each case. Anyway, just my thoughts. On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls mailto:kristof.be...@arm.com>> wrote: Hi Zach, Thanks for putting the data in a spreadsheet - that’s easier to navigate. And thanks for re-raising the question whether we have the right components in bugzilla. As I think this could be an area for lots of different opinions, without any near-perfect solution, it has the potential to be a discussion that drags on for a long time. I thought half of all bugs not getting triaged was a serious enough problem to try and tackle first (with this mail thread) before aiming to improve the component breakdo
Re: [lldb-dev] [CMake] LLDB framework / shared library
cc lldb-dev since the original message cc'd it. On 11/9/18, 12:31 PM, "Alex Langford" wrote: Hi Stefan, Thanks for taking the time to improve LLDB's CMake infrastructure! (1) I don't entirely remember the reason I had separated them out into separate targets. A post-build step would be fine, so feel free to merge these. (2) I have no problems with this. If I remember correctly, I wanted to put everything into LLDBFramework.cmake originally and include it if LLDB_BUILD_FRAMEWORK got set, but that proved more difficult than I realized. I think what you are suggesting is better than what I ended up doing. Feel free to make that change. (3) I think this is a good idea. I found this confusing as well. (4) If that is the case, I think I agree that the Xcode behavior is better. (5) I'm not sure that this is going to actually simplify things. I don't think it's possible to do in source/API/CMakeLists.txt because the tools haven't been added as targets yet. With the current CMake logic, you could pull this logic into its own section that happens after the tools are added as targets. I don't find this any better than what we have now. (6) I'm not sure why this is the case actually. I believe this was added by beanz originally, I just moved this check to be closer to the beginning of the build. If it works with CMake versions less than 3.7 then I have no issues with removing it. Let me know if something is unclear or you have further questions/concerns. Alex On 11/9/18, 9:38 AM, "sgraen...@apple.com on behalf of Stefan Gränitz" wrote: Hello Alex, hello Pavel I spent some time creating/streamlining our CMake infrastructure downstream of LLDB and learned a few things about bundles, versions, code-signing etc. (mostly on the Darwin side of things). I am currently sorting out what can be upstreamed and prepare reviews. Some work is still todo for the LLDB shared library/framework (for simplicity I will call it LLDB.framework). It would be great to know, if you have concerns or comments on the following points: (1) The liblldb target builds the actual LLDB.framework, while the lldb-framework target adds headers, symlinks, etc. What is the reason for this separation? Can I merge that into one target with post-build steps? (2) In previous reviews there was an effort to centralize the code for building LLDB.framework, which makes sense to me. With the current LLDBFramework.cmake approach, however, it’s spread over at least 3 different files (lldb/CMakeLists.txt for init and lldb/source/API/CMakeLists.txt for actual definition). In a similar case downstream, I did all that in a single CMakeLists.txt in the source folder. While I see that LLDBFramework affects the whole project, I don’t see why we need a separate LLDBFramework.cmake (BTW upstream it’s included only once). Do you think I can move things to lldb/source/API/CMakeLists.txt where possible? (3) Currently the build directory for LLDB.framework is determined from LLDB_FRAMEWORK_INSTALL_DIR, which I think is a little confusing. Can I clean this up? (e.g. having a LLDB_FRAMEWORK_BUILD_DIR) (4) With Xcode, executables are emitted in bin and copied to LLDB.framework where necessary. CMake emits them into LLDB.framework directly and creates symlinks to bin. With LLVM_EXTERNALIZE_DEBUGINFO on Darwin, this has the effect, that by default their dSYMs will end up in LLDB.framework. Thus, I would prefer the Xcode behaviour here. (5) Couldn’t (4) also simplify the INCLUDE_IN_SUITE logic? I would consider it to be LLDB.framework’s responsibility to set dependencies and adjust RPATHs for all required artefacts. The tools wouldn’t need to care about that (though, they could still check LLDB_BUILD_FRAMEWORK). The RPATH-login for case ARG_INCLUDE_IN_SUITE && LLDB_BUILD_FRAMEWORK is quite complicated though and I wonder if there are strong reasons not to do that. What do you think? (6) Just out of interest: why is LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7? Best Stefan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Problems `target variable` command.
I tried to run this command: (lldb) target variable "std::numeric_limits::max_exponent" In Variable.cpp:386 we run a regex against the input string which results in the above string being cut down to just `std::numeric_limits`. So then I search my debug info and don't find anything. What I need is for this string to be passed precisely as is to SymbolFile::FindGlobalVariables. My question is: is this just a limitation of `target variables` that is by design, or can this be fixed? Note that I think even C++14 variable templates are broken because of this, so if someone writes: template constexpr T Pi = T(3.1415926535897932385L); And inside of LLDB they write `target variable Pi` it won't work. I think the DWARF and PDB are fundamentally different here in that in DWARF you've got a DW_TAG_variable whose name is Pi and it will have DW_TAG_template_type_parameter of type long double. However, in PDB the only way to find this is by actually searching for the string Pi (or whatever instantiation you want). If you just search for Pi it will be impossible to find. So, I think there are two problems to fix: 1) We need to search for the exact thing the user types, and if that fails, then try using the Regex expression. That will fix the problem for PDB. 2) It doesn't even work for DWARF currently because the regex filter throws away the . So it does find all of the DW_TAG_variables whose name is Pi, but then it tries to evaluate as a sub-expression, which obviously isn't correct. Thoughts? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
