search for: diagnostics

Hi all, I'm working on improvements to diagnostics handling in LLVM, specifically for the benefit of the (integrated) assembler. The goal is to support options such as -Werror, -w, and -W<warning> for files assembled with clang and inline assembly. Clang already has support for these options but does not apply them to diagnostics originating...

...hings: >> >> A much more broad set of callback machinery that allows the backend to >> communicate values or other information back to the front end that can >> then decide what to do. We can define an interface around this, but >> instead of having the backend vending diagnostics we have the callback >> take a "do something with this value" which can just be "communicate >> it back to the front end" or a diagnostic callback can be passed down >> from the front end, etc. >> >> This will probably take a bit more design to get...

...s scales very poorly. Simply put: diagnostic handlers aren't library friendly. It's tough enough to get all libraries to agree on an error type, without having them all agree on a diagnostic handlers too, and thread them everywhere. > This highlights why I think it is important to keep diagnostics and > errors separate. In the solution you have there is a need to allocate > a std::string, even if that is never used. Errors are only constructed on the error path. There is no construction on the success path. > If it was always a > std::string it would not be that bad, but the fr...

I think having diagnostics interface similar to Clang's would be good. I think the total number of defined warnings would be much smaller than Clang. On Mon, Oct 7, 2013 at 3:19 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Ping ? > > > On 10/4/2013 10:41 PM, Shankar Easwaran wrote: > &...

On Wed, Feb 10, 2016 at 6:47 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > >> This highlights why I think it is important to keep diagnostics and > >> errors separate. In the solution you have there is a need to allocate > >> a std::string, even if that is never used. > > > > Errors are only constructed on the error path. There is no construction > on > > the success path. > > But they are alw...

Hi, all, I build clang-tidy by "ninja clang-tidy", but when I run below command, I get no checks. Where is the clang-diagnostic* checkers? Thanks in advance. > $ /Users/zyg/Documents/workspace/llvm-project/llvm/cmake-build-debug/bin/clang-tidy --checks="-*,clang-diagnostic-*" --list-checks No checks enabled.

...aught up on an old thread. I haven't been involved in discussions of this. > > On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> First, let me try to clarify my proposal, in case there was any confusion about that. LLVMContext already has a hook for diagnostics, setInlineAsmDiagnosticHandler() et al. I was suggesting that we rename those interfaces to be more generic, add a simple enumeration of whatever diagnostics can be produced from the backend, and add support in clang for mapping those enumeration values to the corresponding clang diagnostics. Thi...

...ach backend diagnostic with the right number of > placeholders, etc. I'm sort of in two minds about that - I like the > idea that frontends keep all the user-rendered text (means > localization issues are in one place, the frontend - rather than > ending up with english text backend diagnostics rendered in a > non-english client (yeah, pretty hypothetical, I'm not sure anyone has > localized uses of LLVM)). But this does mean that there's no "free > ride" - frontends must have some explicit handling of each backend > diagnostic (some crappy worst-case fallbac...

...nostic with the right number of >> placeholders, etc. I'm sort of in two minds about that - I like the >> idea that frontends keep all the user-rendered text (means >> localization issues are in one place, the frontend - rather than >> ending up with english text backend diagnostics rendered in a >> non-english client (yeah, pretty hypothetical, I'm not sure anyone has >> localized uses of LLVM)). But this does mean that there's no "free >> ride" - frontends must have some explicit handling of each backend >> diagnostic (some crappy wo...

Hi Rafael, > The main thing I like about the diagnostic system is that it lets us > differentiate two related but independent concepts: > > * Giving the human using the program diagnostics about what went wrong. > * Propagating an error to the caller so that the upper library layer > can handle it or pass it up the stack. I don't think these are really independent. Whether or not you need to emit a diagnostic depends on whether a caller can handle the corresponding error,...

...IDE integration to provide additional information about functions and >> loops on demand.) > > I think we definitely need this. In fact, I tried adding something simple earlier this year but gave up when I realized that the task was bigger than I expected. We already have a hook for diagnostics that can be easily extended to handle warnings as well as errors (which is what I tried earlier), but the problem is that it is hardwired for inline assembly errors. To do this right, new warnings really need to be associated with warning groups so that can be controlled from the front-end. >...

Hi, lld doesnot have a Diagnostics interface, It uses llvm::errs() to display errors after linking has been done. I think the Diagnostics interface follow similiar interface patterns as followed by clang (using Diagnostic td files). What do you think ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member o...

RFC: lld- Add visual studio compatible diagnostics output to lld Hello all, We have a proposal to extend the diagnostics output capabilities of lld. ## Problem MS Visual Studio expects the diagnostic output of build tools to conform to a specific format, described here: [1] and [2] . Currently lld cannot emit warnings and errors in this format....

...ust getting caught up on an old thread. I haven't been involved in discussions of this. On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> wrote: > First, let me try to clarify my proposal, in case there was any confusion about that. LLVMContext already has a hook for diagnostics, setInlineAsmDiagnosticHandler() et al. I was suggesting that we rename those interfaces to be more generic, add a simple enumeration of whatever diagnostics can be produced from the backend, and add support in clang for mapping those enumeration values to the corresponding clang diagnostics. Thi...

This is a proposal for either adding a new, or updating an existing command line option such that a diagnostic can optionally be produced for unused -D macros. Long-lived large projects with thousands of files and many contributors have a tendency to accumulate build options over time. As time passes some build options like macros become replaced, obsolete, or simply no longer used. At the same

...hanks all for the insight comments. Let me sum up at a high level what proposals we actually have (sorry if I misinterpreted or missed something, do not hesitate to correct me): 1. Make LLVM defines some APIs that exposes some internal information so that a front-end can use them to build-up some diagnostics. 2. Make LLVM builds up a diagnostic and let a front-end maps this diagnostic to the right warning/error group. In my opinion, both approaches are orthogonal and have different advantages based on what goal we are pursuing. To be more specific, with the first approach, front-end people can come...

On Mon, Oct 7, 2013 at 3:36 PM, Rui Ueyama <ruiu at google.com> wrote: > I think having diagnostics interface similar to Clang's would be good. Much like the options library, it has been a long-term desire to refactor all of the Clang diagnostics infrastructure into a largely independent library that could be used by lots of different tools, Clang, LLD, and even some internal tools that wou...

...sight comments. > > Let me sum up at a high level what proposals we actually have (sorry if I misinterpreted or missed something, do not hesitate to correct me): > > 1. Make LLVM defines some APIs that exposes some internal information so that a front-end can use them to build-up some diagnostics. > > 2. Make LLVM builds up a diagnostic and let a front-end maps this diagnostic to the right warning/error group. > > > In my opinion, both approaches are orthogonal and have different advantages based on what goal we are pursuing. > > To be more specific, with the first...

...n old thread. I haven't been involved in discussions of this. >> >> On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>> First, let me try to clarify my proposal, in case there was any confusion about that. LLVMContext already has a hook for diagnostics, setInlineAsmDiagnosticHandler() et al. I was suggesting that we rename those interfaces to be more generic, add a simple enumeration of whatever diagnostics can be produced from the backend, and add support in clang for mapping those enumeration values to the corresponding clang diagnostics. Thi...

Hello, I have the same error, server is auto rebooted during every boot with kernel XEN, HS20 with Debian Wheezy and XEN hang on and AMM managment show same errors described in previous mails. With Debian wheezy wit non-xen kernel boots correcte, it seems that problems is with xen kernel Same Server HS20 with Debian Lenny+ XEN 3.2 or Debian Squeeze+XEN 4.0 working perfect Upgraded to Debian