Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[James Henderson via lldb-dev]

My only concern is the ability to get auto-subscribed onto issues for
specific tools (i.e. the setup I currently have). If that can be resolved
in a satisfactory manner, then I'm all for this (although less than two
weeks seems like a rather ambitious time to switch over...). If it can't,
then I'd be opposed to switching at all.

On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> > Hi,
> >
> >
> >
> >
> > On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org > wrote:
> >
> > On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > > We held a round-table at the llvm dev conference about what other
> pieces of Github infrastructure we may want to use. This thread in
> particular is about switching to github issue tracking. Use of other parts
> of Github functionality was also discussed -- but that should be for other
> email threads.
> > >
> > > Most of the ideas here were from other people. I /believe/ this
> proposal represents the overall feeling of the folks at the round-table, in
> spirit if not in exact details, but nobody else has reviewed this text, so
> I can't make any specific such claim as to who the "we" represents, other
> than myself. Just assume all the good ideas here were from others, and all
> the bad parts I misremembered or invented.
> > >
> > >
> >
> > Hi,
> >
> > I want to restart this discussion.  There seemed to be support for
> this,
> > but we got held up trying to decide on the appropriate set of tags to
> > use to classify issues.
> >
> > I propose that we move forward with this proposal and disable
> creation of
> > new bugs in bugzilla on Feb 11, and require all new bugs be filed
> via GitHub
> > issues from that date forward.
> >
> > I think that for choosing the tags to use, we should just take
> requests
> > from the community over the next week and add whatever is asked
> for.  The main
> > purpose of adding tags is so we can setup cc lists for bugs, so I
> think this
> > is a good way to ensure that we have tags people care about.  We can
> always
> > add more tags later if necessary.
> >
> >
> > Do we have a way for individuals to get individually automatically
> subscribed on all the bugs created for a given tag?
> > Mailing-lists seem fairly rigid in terms of granularity with respect to
> tags.
> >
>
> When I said cc lists, I really meant auto-subscribe lists, I didn't mean
> that we would start sending issue emails to mailing lists.
>
> From what I can tell, there are a couple different ways to auto-subscribe
> people using github actions.  I think the most simple would be to use
> the assignee field, but I think it's also possible by @ mentioning people
> directly in a comment or @ mentioning teams.
>
> I was planning to experiment more with this over the next few days.
>
> -Tom
>
>
>
>
>
> > --
> > Mehdi
> >
> >
> >
> >
> >
> >
> > What does everyone think about this?
> >
> > -Tom
> >
> >
> > > Background
> > > 
> > > Our bugzilla installation is...not great. It's been not-great for
> a long time now.
> > >
> > > Last year, I argued against switching to github issues. I was
> somewhat optimistic that it was possible to improve our bugzilla in some
> incremental ways...but we haven't. Additionally, the upstream bugzilla
> project was supposed to make a new release of bugzilla ("harmony"), based
> on bugzilla.mozilla.org  <
> http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we
> would be able to upgrade to that. But there has been no such release, and
> not much apparent progress towards such. I can't say with any confidence
> that there will ever be. I no longer believe it really makes sense to
> continue using bugzilla.
> > >
> > > This year, we again discussed switching. This time, nobody really
> spoke up in opposition. So, this time, instead of debating /whether/ we
> should switch, we discussed /how/ we should switch. And came up with a plan
> to switch quickly.
> > >
> > > GitHub issues may not be perfect, but I see other similarly-large
> projects using it quite successfully (e.g. rust-lang/rust) -- so I believe
> it should be good for us, as well. Importantly, Github Issues is
> significantly less user-hostile than our bugzilla is, for new contributors
> and downstream developers who just want to tell us about bugs!
> > >
> > >
> > > Proposal
> > > 
> > > We propose to enable Github issues for the llvm-project repository
> in approximately two weeks from now, and instruct everyone to start filing
> new issues there, rather than in bugzilla.
> > >
> > > Some things we'd like to get in place before turning on Github's
> Issue tracker:
> > > 1. Updated documentation.
> > > 2. An initial set of issue tags w

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 01/31/2020 01:21 AM, James Henderson wrote:
> My only concern is the ability to get auto-subscribed onto issues for 
> specific tools (i.e. the setup I currently have). If that can be resolved in 
> a satisfactory manner, then I'm all for this (although less than two weeks 
> seems like a rather ambitious time to switch over...). If it can't, then I'd 
> be opposed to switching at all.
> 

Would you be able to help me test some potential solutions for this?

-Tom

> On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> 
> On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> > Hi,
> >
> >
> >
> >
> > On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > > We held a round-table at the llvm dev conference about what other 
> pieces of Github infrastructure we may want to use. This thread in particular 
> is about switching to github issue tracking. Use of other parts of Github 
> functionality was also discussed -- but that should be for other email 
> threads.
> > >
> > > Most of the ideas here were from other people. I /believe/ this 
> proposal represents the overall feeling of the folks at the round-table, in 
> spirit if not in exact details, but nobody else has reviewed this text, so I 
> can't make any specific such claim as to who the "we" represents, other than 
> myself. Just assume all the good ideas here were from others, and all the bad 
> parts I misremembered or invented.
> > >
> > >
> >
> > Hi,
> >
> > I want to restart this discussion.  There seemed to be support for 
> this,
> > but we got held up trying to decide on the appropriate set of tags 
> to
> > use to classify issues.
> >
> > I propose that we move forward with this proposal and disable 
> creation of
> > new bugs in bugzilla on Feb 11, and require all new bugs be filed 
> via GitHub
> > issues from that date forward.
> >
> > I think that for choosing the tags to use, we should just take 
> requests
> > from the community over the next week and add whatever is asked 
> for.  The main
> > purpose of adding tags is so we can setup cc lists for bugs, so I 
> think this
> > is a good way to ensure that we have tags people care about.  We 
> can always
> > add more tags later if necessary.
> >
> >
> > Do we have a way for individuals to get individually automatically 
> subscribed on all the bugs created for a given tag?
> > Mailing-lists seem fairly rigid in terms of granularity with respect to 
> tags.
> >
> 
> When I said cc lists, I really meant auto-subscribe lists, I didn't mean
> that we would start sending issue emails to mailing lists.
> 
> From what I can tell, there are a couple different ways to auto-subscribe
> people using github actions.  I think the most simple would be to use
> the assignee field, but I think it's also possible by @ mentioning people
> directly in a comment or @ mentioning teams.
> 
> I was planning to experiment more with this over the next few days.
> 
> -Tom
> 
> 
> 
> 
> 
> > --
> > Mehdi
> >
> >
> >
> > 
> >
> >
> > What does everyone think about this?
> >
> > -Tom
> >
> >
> > > Background
> > > 
> > > Our bugzilla installation is...not great. It's been not-great for 
> a long time now.
> > >
> > > Last year, I argued against switching to github issues. I was 
> somewhat optimistic that it was possible to improve our bugzilla in some 
> incremental ways...but we haven't. Additionally, the upstream bugzilla 
> project was supposed to make a new release of bugzilla ("harmony"), based on 
> bugzilla.mozilla.org  
>  's fork, which is 
> much nicer. I thought we would be able to upgrade to that. But there has been 
> no such release, and not much apparent progress towards such. I can't say 
> with any confidence that there will ever be. I no longer believe it really 
> makes sense to continue using bugzilla.
> > >
> > > This year, we again discussed switching. This time, nobody really 
> spoke up in opposition. So, this time, instead of debating /whether/ we 
> should switch, we discussed /how/ we should switch. And came up with a plan 
> to switch quickly.
> > >
> > > GitHub issues may not be perfect, but I see other similarly-large 
> projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it 
> should be good for us, as well. Importantly, Github Issues is significantly 
> less user-hostile than our bu

[lldb-dev] [Bug 44736] New: Incorrect use of llvm::toStringRef in TypeSystem.cpp

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=44736

Bug ID: 44736
   Summary: Incorrect use of llvm::toStringRef in TypeSystem.cpp
   Product: lldb
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: cebtenz...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Commit 0e252e3 ("[Symbol] Use llvm::Expected when getting TypeSystems")
introduced several calls to llvm::toStringRef in
'lldb/source/Symbol/TypeSystem.cpp', each with a single 'const char *'
argument. The best matching overload is llvm::toStringRef(bool), resulting in
some unhelpful error messages.


Expected Behavior:

Internal error messages look like "TypeSystem for language swift doesn't
exist".


Actual Behavior:

Internal error messages look like "TypeSystem for language true doesn't exist".

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 44736] Incorrect use of llvm::toStringRef in TypeSystem.cpp

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=44736

Jonas Devlieghere  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |jdevliegh...@apple.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers 
 wrote:
> 
> It took a bit longer than planned due to master being a somewhat
> unstable at the branch point, but Release Candidate 1 has now been
> tagged as llvmorg-10.0.0-rc1.

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11 (I will post i386 results as they become
available):

  Expected Passes: 67894
  Expected Failures  : 268
  Unsupported Tests  : 4653
  Unexpected Passes  : 5
  Unexpected Failures: 541
  Individual Timeouts: 18

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
751f2d86eede35a201db524a78ebb0e9d48b71d120b44153f961edb666d30c96

Unfortunately the test-suite did not build at all, as all the Bitcode
compilations failed with segfaults, similar to the following run under
gdb:

Starting program: 
/home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
 -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT 
Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
 -MF 
Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d
 -o 
Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
 -c 
/home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc

Program received signal SIGSEGV, Segmentation fault.
0x0001000f in ?? ()
(gdb) bt
#0  0x0001000f in ?? ()
#1  0x028ca9c0 in 
llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
#2  0x02e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#3  0x02e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#4  0x02e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#5  0x035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
const&, llvm::Module*, clang::BackendAction, 
std::__1::unique_ptr >) ()
#6  0x03c17e67 in clang::CodeGenAction::ExecuteAction() ()
#7  0x03b7abca in clang::FrontendAction::Execute() ()
#8  0x03aea761 in 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#9  0x03c12905 in 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#10 0x01cbaf0e in cc1_main(llvm::ArrayRef, char const*, 
void*) ()
#11 0x01cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl&) ()
#12 0x039eb297 in void llvm::function_ref::callback_fn
 >, std::__1::basic_string, 
std::__1::allocator >*, bool*) const::$_1>(long) ()
#13 0x033e406a in 
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) ()
#14 0x039ea7f0 in 
clang::driver::CC1Command::Execute(llvm::ArrayRef
 >, std::__1::basic_string, 
std::__1::allocator >*, bool*) const ()
#15 0x039bfc5c in 
clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, 
clang::driver::Command const*&) const ()
#16 0x039c01ac in 
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, 
llvm::SmallVectorImpl >&) 
const ()
#17 0x039d336c in 
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, 
llvm::SmallVectorImpl >&) ()
#18 0x01cb884f in main ()

Looks like the bitcode compilation path is totally busted?  Anybody know
an open bug for this?

-Dimitry



fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Michał Górny via lldb-dev]

On Thu, 2020-01-30 at 14:38 -0500, Hans Wennborg via Release-testers
wrote:
> 
Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr44555
> 
> Release testers: please start your engines, run the script, share your
> results, and upload binaries.
> 

Gentoo/amd64 issues (with 32-bit multilib where available):

- libc++ stand-alone builds were broken; revert was committed
  as 3573526c028;  with that patch, all tests pass for me.

- there's one openmp issue on 32-bit build:
  https://bugs.llvm.org/show_bug.cgi?id=44733
  
- I've found an LLDB bug with linking liblldb.so in tests.
  I don't think it's strictly a regression but I don't recall noticing
  it before.  I've started working on a patch:
  https://reviews.llvm.org/D73767

  However, I'm not sure if it's worth backporting.  There's still
  a plethora of failing tests, plus some lit bug causing it to hang
  at the end, and I don't think I'll find time to look into any of this
  anytime soon.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Fangrui Song via lldb-dev]

On 2020-01-31, Tom Stellard via llvm-dev wrote:

On 01/31/2020 01:21 AM, James Henderson wrote:

My only concern is the ability to get auto-subscribed onto issues for specific 
tools (i.e. the setup I currently have). If that can be resolved in a 
satisfactory manner, then I'm all for this (although less than two weeks seems 
like a rather ambitious time to switch over...). If it can't, then I'd be 
opposed to switching at all.



Would you be able to help me test some potential solutions for this?


My feeling is similar to James'.

+1 if auto subscription is available (similar to Herald rules).
-1 if it isn't.

And I guess contributors may need to change the notification setting from "Watching" to 
"Not watching",
to avoid issue spam.


Tom, I'd like to be a tester.




On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote:

On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> Hi,
>
>
>
>
> On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org> >> wrote:
>
> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > We held a round-table at the llvm dev conference about what other 
pieces of Github infrastructure we may want to use. This thread in particular is 
about switching to github issue tracking. Use of other parts of Github functionality 
was also discussed -- but that should be for other email threads.
> >
> > Most of the ideas here were from other people. I /believe/ this proposal 
represents the overall feeling of the folks at the round-table, in spirit if not in exact 
details, but nobody else has reviewed this text, so I can't make any specific such claim as to 
who the "we" represents, other than myself. Just assume all the good ideas here were 
from others, and all the bad parts I misremembered or invented.
> >
> >
>
> Hi,
>
> I want to restart this discussion.  There seemed to be support for 
this,
> but we got held up trying to decide on the appropriate set of tags to
> use to classify issues.
>
> I propose that we move forward with this proposal and disable 
creation of
> new bugs in bugzilla on Feb 11, and require all new bugs be filed via 
GitHub
> issues from that date forward.
>
> I think that for choosing the tags to use, we should just take 
requests
> from the community over the next week and add whatever is asked for.  
The main
> purpose of adding tags is so we can setup cc lists for bugs, so I 
think this
> is a good way to ensure that we have tags people care about.  We can 
always
> add more tags later if necessary.
>
>
> Do we have a way for individuals to get individually automatically 
subscribed on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to 
tags.
>

When I said cc lists, I really meant auto-subscribe lists, I didn't mean
that we would start sending issue emails to mailing lists.

From what I can tell, there are a couple different ways to auto-subscribe
people using github actions.  I think the most simple would be to use
the assignee field, but I think it's also possible by @ mentioning people
directly in a comment or @ mentioning teams.

I was planning to experiment more with this over the next few days.

-Tom





> --
> Mehdi
>
>
>
>
>
>
> What does everyone think about this?
>
> -Tom
>
>
> > Background
> > 
> > Our bugzilla installation is...not great. It's been not-great for a 
long time now.
> >
> > Last year, I argued against switching to github issues. I was somewhat optimistic that it was 
possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla 
project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org 
  's 
fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and 
not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer 
believe it really makes sense to continue using bugzilla.
> >
> > This year, we again discussed switching. This time, nobody really 
spoke up in opposition. So, this time, instead of debating /whether/ we should 
switch, we discussed /how/ we should switch. And came up with a plan to switch 
quickly.
> >
> > GitHub issues may not be perfect, but I see other similarly-large 
projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should 
be good for us, as well.

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Fangrui Song via lldb-dev]

On 2020-01-30, Anton Korobeynikov via cfe-dev wrote:

Will you be able to start numbering in github at a number larger than the 
largest bug in bugzilla?  It would be annoying to have overlapping bug numbers. 
 Bug numbers exist in code comments, list archives, etc., etc.  If someone 
reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real 
shame.

This won't work in general, unfortunately as there are already a bunch
of PRs and issues opened... And github uses consecutive numbering for
all PRs, issues and such... So, there is already overlap here.


It'd be nice if Github allows to bump the issue counter to 44000+ .
(current largest https://bugs.llvm.org/show_bug.cgi?id= id is 44000+)

Then the website can set up a redirector:

http://llvm.org/PR1 => https://bugs.llvm.org/show_bug.cgi?id=1
...
http://llvm.org/PR44000 => https://bugs.llvm.org/show_bug.cgi?id=44000
...
http://llvm.org/PR45000 => https://github.com/llvm/llvm-project/issue/45000
http://llvm.org/PR5 => https://github.com/llvm/llvm-project/issue/5
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 44748] New: ObjectFile/ELF tests fail due to mismatched ID

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=44748

Bug ID: 44748
   Summary: ObjectFile/ELF tests fail due to mismatched ID
   Product: lldb
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: mgo...@gentoo.org
CC: jdevliegh...@apple.com, lab...@google.com,
llvm-b...@lists.llvm.org

lldb-shell :: ObjectFile/ELF/PT_LOAD-overlap-PT_INTERP.yaml
lldb-shell :: ObjectFile/ELF/PT_LOAD-overlap-PT_TLS.yaml
lldb-shell :: ObjectFile/ELF/PT_LOAD-overlap-section.yaml
lldb-shell :: ObjectFile/ELF/PT_LOAD.yaml
lldb-shell :: ObjectFile/ELF/PT_TLS-overlap-PT_LOAD.yaml


All of them seem to suffer from expecting 64-bit ID in output but getting
32-bit value instead, e.g.:

/home/mgorny/llvm-project.real/lldb/test/Shell/ObjectFile/ELF/PT_LOAD-overlap-PT_INTERP.yaml:8:15:
error: CHECK-NEXT: expected string not found in input
# CHECK-NEXT: ID: 0xfffe
  ^
:11:2: note: scanning from here
 ID: 0xfffe
 ^


I'm wondering whether this is intentional (i.e. tests need to be fixed) or the
code should be using a 64-bit unconditionally.  If the former, should we try to
split the tests or maybe just hack it around in lldb-test?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev