| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
PiperOrigin-RevId: 286906740
|
|
|
|
|
|
|
|
| |
in `mlir` namespace.
Aside from being cleaner, this also makes the codebase more consistent.
PiperOrigin-RevId: 286206974
|
|
|
|
|
|
|
| |
Closes tensorflow/mlir#290
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
PiperOrigin-RevId: 284169681
|
|
|
|
|
|
| |
It is often desirable to know where within the program that a diagnostic was emitted, without reverting to assert/unreachable which crash the program. This change adds a flag `mlir-print-stacktrace-on-diagnostic` that attaches the current stack trace as a note to every diagnostic that gets emitted.
PiperOrigin-RevId: 283996373
|
|
|
|
|
|
| |
This causes the AsmPrinter to use a local value numbering when printing the IR, allowing for the printer to be used safely in a local context, e.g. to ensure thread-safety when printing the IR. This means that the IR printing instrumentation can also be used during multi-threading when module-scope is disabled. Operation::dump and DiagnosticArgument(Operation*) are also updated to always print local scope, as this is the most common use case when debugging.
PiperOrigin-RevId: 279988203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies defining expected-* directives when there are multiple that apply to the next or previous line. @below applies the directive to the next non-designator line, i.e. the next line that does not contain an expected-* designator. @above applies to the previous non designator line.
Examples:
// Expect an error on the next line that does not contain a designator.
// expected-remark@below {{remark on function below}}
// expected-remark@below {{another remark on function below}}
func @bar(%a : f32)
// Expect an error on the previous line that does not contain a designator.
func @baz(%a : f32)
// expected-remark@above {{remark on function above}}
// expected-remark@above {{another remark on function above}}
PiperOrigin-RevId: 276369085
|
|
|
|
|
|
| |
Closes tensorflow/mlir#177
PiperOrigin-RevId: 275692653
|
|
|
|
|
|
|
| |
That space is 4 StringRefs, not 3, because element 0 of the match always
contains the entire source string.
PiperOrigin-RevId: 273875606
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a problem with current save-restore pattern of diagnostics handlers, as there may be a thread race between when the previous handler is destroyed. For example, this occurs when using multiple ParallelDiagnosticHandlers asynchronously:
Handler A
Handler B | - LifeTime - | Restore A here.
Handler C | --- LifeTime ---| Restore B after it has been destroyed.
The new design allows for multiple handlers to be registered in a stack like fashion. Handlers can return success() to signal that they have fully processed a diagnostic, or failure to propagate otherwise.
PiperOrigin-RevId: 270720625
|
|
|
|
| |
PiperOrigin-RevId: 270632324
|
|
|
|
|
|
| |
This allows for the use of multiple ParallelDiagnosticHandlers without having them conflict with each other.
PiperOrigin-RevId: 268967407
|
|
|
|
|
|
|
|
| |
Switch to C++14 standard method as llvm::make_unique has been removed (
https://reviews.llvm.org/D66259). Also mark some targets as c++14 to ease next
integrates.
PiperOrigin-RevId: 263953918
|
|
|
|
|
|
|
|
|
| |
This can result in index expression overflow in "Loc.getPointer() - ColumnNo"
in SourgeMgr.
loc could also be prefixed to the message additionally in this case.
PiperOrigin-RevId: 262935408
|
|
|
|
|
|
| |
Printing 'loc(unknown)' just clutters the output with unhelpful information.
PiperOrigin-RevId: 257883717
|
|
|
|
|
|
|
|
| |
into the mlir namespace.
Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups.
PiperOrigin-RevId: 255112791
|
|
|
|
|
|
| |
behavior of InFlightDiagnostic and enables notes to be converted to failure.
PiperOrigin-RevId: 254579098
|
|
|
|
|
|
| |
This will allow for locations to be used in the same contexts as attributes. Given that attributes are nullable types, the 'Location' class now represents a non-nullable wrapper around a 'LocationAttr'. This preserves the desired semantics we have for non-optional locations.
PiperOrigin-RevId: 254505278
|
|
|
|
|
|
| |
preparation for making the location classes attributes instead of separate IR types.
PiperOrigin-RevId: 253860058
|
|
|
|
|
|
|
|
| |
SourceMgrDiagnosticHandlers.
--
PiperOrigin-RevId: 250974331
|
|
|
|
|
|
|
|
| |
with ''.
--
PiperOrigin-RevId: 249935489
|
|
|
|
|
|
|
|
| |
simplify saving and restoring the currently registered handler.
--
PiperOrigin-RevId: 249735912
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249466645
|
|
|
|
|
|
|
|
| |
available in Diagnostics.h. This provides a common utility for deterministically handling diagnostics in a multi-threaded environment.
--
PiperOrigin-RevId: 249325937
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 248987646
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 248967563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-whitespace if the column is unknown(zero). This also fixes a small bug with call stack printing.
Example:
/tmp/file_C.py:21:5: error: 'foo.bar' op attribute 'something'
raise app.UsageError('Too many command-line arguments.')
^
/tmp/file_D.py:20:3: note: called from
if len(argv) > 1:
^
/tmp/file_E.py:19:1: note: called from
def main(argv):
^
/tmp/file_F.py:24:3: note: called from
app.run(main)
^
--
PiperOrigin-RevId: 248151212
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stacks.
Example:
/tmp/file_C.py:17:1: error: 'foo.bar' op attribute 'something' ...
app.run(main)
^
/tmp/file_D.py:14:1: note: called from
raise app.UsageError('Too many command-line arguments.')
^
/tmp/file_E.py:12:1: note: called from
def main(argv):
^
/tmp/file_F.py:13:1: note: called from
if len(argv) > 1:
^
--
PiperOrigin-RevId: 248074804
|
|
|
|
|
|
|
|
| |
fields/methods to the .cpp file.
--
PiperOrigin-RevId: 247768443
|
|
|
|
|
|
|
|
| |
location/message/kind. This opens the door for many more powerful use cases: fixits, colors, etc.
--
PiperOrigin-RevId: 247705673
|
|
|
|
|
|
|
|
| |
files seen in diagnostics.
--
PiperOrigin-RevId: 247681779
|
|
|
|
|
|
|
|
|
| |
The switch is supposed to be fully covered, but GCC warns that:
"control reaches end of non-void function"
--
PiperOrigin-RevId: 247672430
|
|
|
|
|
|
|
|
| |
FileLineColLoc.
--
PiperOrigin-RevId: 247662828
|
|
|
|
|
|
|
|
| |
the llvm::SourceMgr has no main file.
--
PiperOrigin-RevId: 247605584
|
|
|
|
|
|
|
|
| |
a new llvm::SourceMgr diagnostic handler 'SourceMgrDiagnosticVerifierHandler'. This will allow for other tools to reuse the 'expected-*' functionality.
--
PiperOrigin-RevId: 247514684
|
|
|
|
|
|
|
|
| |
managers with multiple buffers.
--
PiperOrigin-RevId: 247482733
|
|
|
|
|
|
|
|
| |
ability to stream an attribute into a Diagnostic.
--
PiperOrigin-RevId: 247359911
|
|
|
|
|
|
|
|
| |
interface with llvm::SourceMgr. This lowers the barrier of entry for tools to get rich diagnostic handling when using llvm::SourceMgr.
--
PiperOrigin-RevId: 247358610
|
|
|
|
|
|
|
|
| |
This also adds support for streaming in ranges(e.g. ArrayRef) into a diagnostic with an optional element delimiter.
--
PiperOrigin-RevId: 247239436
|
|
|
|
|
|
|
|
| |
dialects (Affine/Standard/etc.) by using the new stream interface instead of Twine.
--
PiperOrigin-RevId: 246842016
|
|
|
|
|
|
|
|
| |
optional. This allows for the ability to exclusively use the new diagnostic interface without breaking all of the existing usages. Several diagnostics emitted in lib/IR have been updated to make use of this functionality.
--
PiperOrigin-RevId: 246546044
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notes are a way to add additional context to a diagnostic, but don't really make sense as standalone diagnostics. Moving forward, notes will no longer be able to be constructed directly and must be attached to a parent Diagnostic.
Notes can be attached via `attachNote`:
auto diag = ...;
diag.attachNote() << "This is a note";
--
PiperOrigin-RevId: 246545971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InFlightDiagnostic.
The Diagnostic class contains all of the information necessary to report a diagnostic to the DiagnosticEngine. It should generally not be constructed directly, and instead used transitively via InFlightDiagnostic. A diagnostic is currently comprised of several different elements:
* A severity level.
* A source Location.
* A list of DiagnosticArguments that help compose and comprise the output message.
* A DiagnosticArgument represents any value that may be part of the diagnostic, e.g. string, integer, Type, Attribute, etc.
* Arguments can be added to the diagnostic via the stream(<<) operator.
* (In a future cl) A list of attached notes.
* These are in the form of other diagnostics that provide supplemental information to the main diagnostic, but do not have context on their own.
The InFlightDiagnostic class represents an RAII wrapper around a Diagnostic that is set to be reported with the diagnostic engine. This allows for the user to modify a diagnostic that is inflight. The internally wrapped diagnostic can be reported directly or automatically upon destruction.
These classes allow for more natural composition of diagnostics by removing the restriction that the message of a diagnostic is comprised of a single Twine. They should also allow for nice incremental improvements to the diagnostics experience in the future, e.g. formatv style diagnostics.
Simple Example:
emitError(loc, "integer bitwidth is limited to " + Twine(IntegerType::kMaxWidth) + " bits");
emitError(loc) << "integer bitwidth is limited to " << IntegerType::kMaxWidth << " bits";
--
PiperOrigin-RevId: 246526439
|
|
'DiagnosticEngine' and move the diagnostic handler support and final diagnostic emission from the MLIRContext to it.
--
PiperOrigin-RevId: 246163897
|