search for: stringdata

http://bugs.freedesktop.org/show_bug.cgi?id=23505 Summary: KDE's Kubrick has problems with xf86-video-nouveau driver Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at

On Wed, Jul 24, 2013 at 10:23 PM, Chris Lattner <clattner at apple.com> wrote: > On Jul 24, 2013, at 10:16 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> How about this: keep the jist of the current API, but drop the "warning"- or >>> "error"-ness of the API. Instead, the backend just includes an enum value >>> (plus string

...special interest to the LLVM clients (clang, etc.). As long as the plugin has access to the LLVMContext, I do not see why it should not be able to report its own events. See the example below. Note that the proposed prototype changed recently to (see Chris’ email): void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) > Would it be possible for a plugin to provide (limited) warnings/diagnostics without requiring clang/LLVM to be adapted? I think so. Typically, to report a warning, I would do from the plug-in: <get the LLVMContext>.report(Other, “Whatever”, Warning,...

On 07/25/2013 05:09 PM, Quentin Colombet wrote: > Hi, > > I think we have a consensus on how we should report diagnostics now. > For broader uses, the discussion is still open. > > To move forward on the diagnostic part, here is the plan: > - Extend the current handler with a prototype like: > void report(enum Kind, enum Classification, const char* msg) > where > -

Hi, On Jul 25, 2013, at 9:07 PM, Chris Lattner <clattner at apple.com> wrote: > On Jul 25, 2013, at 6:04 PM, David Blaikie <dblaikie at gmail.com> wrote: >>>> void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) >>> >>> The idea is that "StringData+Kind" can be used to format something nice in clang, but that "msg" fully covers it for clients that don't know the Kind enum. Sounds good! >> >> Presumably there are d...

On Jul 25, 2013, at 6:04 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) >> >> The idea is that "StringData+Kind" can be used to format something nice in clang, but that "msg" fully covers it for clients that don't know the Kind enum. > > Presumably there are diagnostics that are going to h...

...arning. >> - msg contains the fall back message to print in case the front-end do not know what to do with the report. >> >> How does this sound? > > Sounds like the right direction, how about extending it a bit more to be: > > >> void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) > > The idea is that "StringData+Kind" can be used to format something nice in clang, but that "msg" fully covers it for clients that don't know the Kind enum. Presumably there are diagnostics that are going to have more than one p...

...gt; - Classification is Error, Warning. > - msg contains the fall back message to print in case the front-end do not know what to do with the report. > > How does this sound? Sounds like the right direction, how about extending it a bit more to be: > void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) The idea is that "StringData+Kind" can be used to format something nice in clang, but that "msg" fully covers it for clients that don't know the Kind enum. -Chris

...LLVM clients (clang, etc.). > As long as the plugin has access to the LLVMContext, I do not see why it should not be able to report its own events. > See the example below. > > Note that the proposed prototype changed recently to (see Chris’ email): > void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) > >> Would it be possible for a plugin to provide (limited) warnings/diagnostics without requiring clang/LLVM to be adapted? > I think so. > Typically, to report a warning, I would do from the plug-in: > <get the LLVMContext>.report(Other...

Hi, I think we have a consensus on how we should report diagnostics now. For broader uses, the discussion is still open. To move forward on the diagnostic part, here is the plan: - Extend the current handler with a prototype like: void report(enum Kind, enum Classification, const char* msg) where - Kind is the kind of report: InlineAsm, StackSize, Other. - Classification is Error, Warning. - msg

...As long as the plugin has access to the LLVMContext, I do not see why it should not be able to report its own events. >>> See the example below. >>> >>> Note that the proposed prototype changed recently to (see Chris’ email): >>> void report(enum Kind, StringRef StringData, enum Classification, StringRef msg) >>> >>>> Would it be possible for a plugin to provide (limited) warnings/diagnostics without requiring clang/LLVM to be adapted? >>> I think so. >>> Typically, to report a warning, I would do from the plug-in: >>>...

...AW]. Misha Koshelev (32): msi: Add OLE automation conformance test. msi: Merge OLE automation conformance tests. msi: Add base class for OLE automation objects. msi: Expand IDL file to contain some OLE automation interface functions. msi: automation: Implement Record::StringData. msi: automation: Implement View::Execute, Fetch, and Close. msi: automation: Implement Database::OpenView. msi: automation: Implement a few functions from the Session object. msi: automation: Implement Installer::OpenPackage. msi: automation: Expose Installer object....

...mplement Installer::CreateRecord. msi/tests: automation: Test invoking methods as properties & vice versa. msi: automation: Return DISP_E_MEMBERNOTFOUND if flags are incorrect. msi: automation: Implement Record::FieldCount. msi/tests: automation: Correct expected Record::StringData PROPERTYPUT return variant type. msi/tests: automation: Add tests for Record::IntegerData. msi/tests: automation: Add test for View::Modify. msi: automation: Implement View::Modify. msi: automation: Implement Record::IntegerData. msi/tests: automation: Add test for Ins...

...ing fixes. gdi/tests: Win64 printf format warning fixes. kernel32: Win64 printf format warning fixes. Mike McCormack (27): msi: Check that transforms preserve tables. msi: Win64 printf format warning fixes. msi: Remove an unused variable. msi: Only declare the szStringData and szStringPool strings once. msi: Only ignore the StringPool and StringData in a transform. kernel32: Return some fake data in FindActCtxSectionStringW. msi: Handle null integers properly in transforms. msi: Transform the _Columns and _Tables tables first so the table meta...