[llvm-dev] [cfe-dev] Your help needed: List of LLVM Open Projects 2017

[Piotr Padlewski via llvm-dev]

2017-01-17 16:56 GMT+01:00 Vassil Vassilev <v.g.vassilev at gmail.com>:

> On 16/01/17 22:13, Piotr Padlewski wrote:
>
> The list can't ommit clang-tidy.
>
> Sure.
>
> There are many ideas about new checks on llvm bugzilla.
> https://llvm.org/bugs/buglist.cgi?product=clang-tools-extra&
> component=clang-tidy&resolution=---&list_id=110936
> Everything matching ".*Feature Request.*"
>
> Can you select 2 promising ideas and wrap them in a 10-week (student)
> project?
> -- Vassil
>
> Yep, I will send you something in few days.


>
> Piotr
>
> 2017-01-16 21:31 GMT+01:00 Sean Silva via cfe-dev <cfe-dev at lists.llvm.org>
> :
>
>> Do we have any open projects on LLD?
>>
>> I know we usually try to avoid any big "projects" and mainly add/fix
>> things in response to user needs, but just wondering if somebody has any
>> ideas.
>>
>> Some really generic/simple stuff I can think of:
>> 1. trying out LLD on a large program corpus and reporting/reducing/fixing
>> bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
>> packages from a linux distro like Debian or Gentoo)
>> 2. performance analysis and optimization of LLD
>> 3. getting LLD to link a bootable Linux kernel and/or GRUB
>> 4. write an input verifier such that LLD can survive intensive fuzzing
>> with no crashes / fatal errors [1] when the verifier says the input is
>> okay. This will allow us to measure what the overhead of doing this
>> actually is.
>>
>>
>> [1] As of the latest LLD discussion (in the thread "[llvm-dev] LLD status
>> update and performance chart") it sounds like people are okay with LLD
>> treating fatal errors the same way that LLVM uses assertions; for inputs
>> from the C++ API, we can document to not pass corrupted object files. For
>> inputs read from files, there is still community interest in at least
>> having the option to run a "verifier" to validate the inputs. I think the
>> best way to approach the verifier is to essentially follow the approach
>> suggested by Peter (in the context of "hardening") in
>> https://llvm.org/bugs/show_bug.cgi?id=30540#c5 i.e. getting to the point
>> where LLD can survive intensive fuzzing.
>>
>> -- Sean Silva
>>
>> On Mon, Jan 16, 2017 at 5:18 AM, Vassil Vassilev via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi folks,
>>>
>>>   Happy new year!
>>>
>>>   Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation
>>> LLVM Developers'. It was suggested that we should update our open projects
>>> page and possibly restructure it a little bit.
>>>
>>>   I volunteered to do this work and I need your help.
>>>
>>>
>>>   Chandler and I started working on a google doc [1]. We pinged few code
>>> owners asking them to list of work items we should get done in 2017 but we
>>> do not have the manpower. Now we would like to ask for your input, too.
>>>
>>>   I believe an up to date list can serve as a good entry point for
>>> students, interns and new contributors.
>>>
>>>   Feel free to propose a new item or comment under an existing one. I
>>> expect to start gradually updating the page beginning of Feb.
>>>
>>> -- Vassil
>>>
>>> [1] https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n
>>> 0dlf6wrzfypiX0YDQBc/edit?usp=sharing
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170118/e94baf42/attachment.html>