In https://github.com/llvm/llvm-project/pull/149248, clang-format
applied some formatting to lines untouched by that PR, because the
existing code is not clang-format compliant. Hence applying clang-format
on the entire files here.
The signature of `CheckTemplateArgValues` implements error handling via
the `bool` return type, yet always returned false. The single possible
error case instead used `PrintFatalError,` which exits the program
afterward.
This behavior is undesirable: It prevents any further errors from being
printed and makes TableGen less usable as a library as it crashes the
entire process (e.g. `tblgen-lsp-server`).
This PR therefore fixes the issue by using `Error` instead and returning
true if an error occurred. All callers already perform proper error
handling.
As `llvm-tblgen` exits on error, a test was also added to the LSP to
ensure it exits normally despite the error.
We can use `deftype` (not using `typedef` here to be consistent
with `def`, `defm`, `defset`, `defvar`, etc) to define type aliases.
Currently, only primitive types and type aliases are supported to be
the source type and `deftype` statements can only appear at the top
level.
Reviewers: fpetrogalli, Artem-B, nhaehnle, jroelofs
Reviewed By: jroelofs, nhaehnle, Artem-B
Pull Request: https://github.com/llvm/llvm-project/pull/79570
enum `RecordKind` is added to indicate the kind of Record (which
can be a normal record definition, anonymous record definition,
class or multiclass).
Some arguments like `IsMC` and `IsDefm` are removed since we can
get the information from `RecordKind`.
The keyword is intended for debugging purpose. It prints a message to
stderr.
This patch is based on code originally written by Adam Nemet, and on the
feedback received by the reviewers in
https://reviews.llvm.org/D157492.
We provide a way to specify arguments in the form of `name=value`
so that we don't have to specify all optional arguments before the
one we'd like to change. Required arguments can alse be specified
in this way.
Note that the argument can only be specified once regardless of
the way (named or positional) to specify and positional arguments
should be put before named arguments.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D152998
A new Init type ArgumentInit is added to represent arguments. We currently only support positional arguments; an upcoming change will add named argument support.
The index of argument in error message is removed.
Differential Revision: https://reviews.llvm.org/D154066
The code to resolve class/multiclass arguments are similar, we
extract them to `resolveArguments`s to simplify code.
Reviewed By: tra, reames
Differential Revision: https://reviews.llvm.org/D154065
In D148197, we have made `defvar` statement able to refer to class
template arguments. However, the priority of class/multiclass
template argument is higher than variables defined by `defvar`, which
is a little counterintuitive.
In this patch, we unify the priority of variables. Each pair of
braces introduces a new scope, which may contain some additional
variables like template arguments, loop iterators, etc. We can
define local variables inside this scope via `defvar` and these
variables are of higher priority than additional variables. This
means that `defvar` will shadow additional variables with the same
name. The scope can be nested, and we use the innermost variable.
This make variables defined by `defvar` prior to class/multiclass
template arguments, loop iterators, etc. The shadow rules now are:
* `V` in a record body shadows a global `V`.
* `V` in a record body shadows template argument `V`.
* `V` in template arguments shadows a global `V`.
* `V` in a `foreach` statement list shadows any `V` in surrounding record or global scopes.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D149016
This enables indexing in `!foreach` and permutation with `list[permlist]`.
Enhancements in syntax:
- `list<int>` is applicable as a slice element.
- `list[int,]` is evaluated as not `ElemType` but `list<ElemType>`
with a single element.
Part of D145872
FIXME: I didn't apply new semantics to BitSlice.
We can't refer to template arguments for defvar statements in class
definitions, or it will report some errors like:
```
error: Variable not defined: 'xxx'.
```
The key point here is we used to pass nullptr to `ParseValue` in
`ParseDefvar`. As a result, we can't refer to template arguments
since `CurRec` is nullptr in `ParseIDValue`.
So we add an argument `CurRec` to `ParseDefvar` and provide it
when parsing defvar statements in class definitions.
Reviewed By: tra, simon_tatham
Differential Revision: https://reviews.llvm.org/D148197
This is extremely useful for language tooling as it allows
for providing go-to-def/find-references/etc. for many
more situations than what is currently possible.
Differential Revision: https://reviews.llvm.org/D134087
Add a warning to TableGen for unused template arguments in classes and
multiclasses, for example:
multiclass Foo<int x> {
def bar;
}
$ llvm-tblgen foo.td
foo.td:1:20: warning: unused template argument: Foo::x
multiclass Foo<int x> {
^
A flag '--no-warn-on-unused-template-args' is added to disable the
warning. The warning is disabled for LLVM and sub-projects if
'LLVM_ENABLE_WARNINGS=OFF'.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D109359
This requires changes to TableGen files and some C++ files due to
incompatible multiclass template arguments that slipped through
before the improved handling.
Rework template argument checking so that all arguments are type-checked
and cast if necessary.
Add a test.
Differential Revision: https://reviews.llvm.org/D96416
Differential Revision: https://reviews.llvm.org/D93911
This first step adds the assert statement and supports it at top level
and in record definitions. Later steps will support it in class
definitions and multiclasses.
Update the documentation and add a test.
Build failed: Change SIZE_MAX to std::numeric_limits<int64_t>::max().
Differential Revision: https://reviews.llvm.org/D93419
Replace Twine.h/SourceMgr.h includes with forward declarations and include in TGParser.cpp
Remove forward declarations we already have to include in Record.h
Summary:
This allows you to make some of the defs in a multiclass or `foreach`
conditional on an expression computed from the parameters or iteration
variables.
It was already possible to simulate an if statement using a `foreach`
with a dummy iteration variable and a list constructed using `!if` so
that it had length 0 or 1 depending on the condition, e.g.
foreach unusedIterationVar = !if(condition, [1], []<int>) in { ... }
But this syntax is nicer to read, and also more convenient because it
allows an else clause.
To avoid upheaval in the implementation, I've implemented `if` as pure
syntactic sugar on the `foreach` implementation: internally, `ParseIf`
actually does construct exactly the kind of foreach shown above (and
another reversed one for the else clause if present).
Reviewers: nhaehnle, hfinkel
Reviewed By: hfinkel
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71474
Summary:
This allows you to define a global or local variable to an arbitrary
value, and refer to it in subsequent definitions.
The main use I anticipate for this is if you have to compute some
difficult function of the parameters of a multiclass, and then use it
many times. For example:
multiclass Foo<int i, string s> {
defvar op = !cast<BaseClass>("whatnot_" # s # "_" # i);
def myRecord {
dag a = (op this, (op that, the other), (op x, y, z));
int b = op.subfield;
}
def myOtherRecord<"template params including", op>;
}
There are a couple of ways to do this already, but they're not really
satisfactory. You can replace `defvar x = y` with a loop over a
singleton list, `foreach x = [y] in { ... }` - but that's unintuitive
to someone who hasn't seen that workaround idiom before, and requires
an extra pair of braces that you often didn't really want. Or you can
define a nested pair of multiclasses, with the inner one taking `x` as
a template parameter, and the outer one instantiating it just once
with the desired value of `x` computed from its other parameters - but
that makes it awkward to sequentially compute each value based on the
previous ones. I think `defvar` makes things considerably easier.
You can also use `defvar` at the top level, where it inserts globals
into the same map used by `defset`. That allows you to define global
constants without having to make a dummy record for them to live in:
defvar MAX_BUFSIZE = 512;
// previously:
// def Dummy { int MAX_BUFSIZE = 512; }
// and then refer to Dummy.MAX_BUFSIZE everywhere
Reviewers: nhaehnle, hfinkel
Reviewed By: hfinkel
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71407
This error was originally added a while(7 years) ago when
including multiple files was basically always an error. Tablegen
now has preprocessor support, which allows for building nice
c/c++ style include guards. With the current error being
reported, we unfortunately need to double guard when including
files:
* In user of MyFile.td
#ifndef MYFILE_TD
include MyFile.td
#endif
* In MyFile.td
#ifndef MYFILE_TD
#define MYFILE_TD
...
#endif
Differential Revision: https://reviews.llvm.org/D70410
This allows using anything that isn't a literal integer as the bounds
for a foreach. Some of the diagnostics aren't perfect, but nobody ever
accused tablegen of having good errors. For example, the existing
wording suggests a bitrange is valid, but as far as I can tell this
has never worked.
Fixes bug 41958.
llvm-svn: 361434
This patch extends TableGen language with !cond operator.
Instead of embedding !if inside !if which can get cumbersome,
one can now use !cond.
Below is an example to convert an integer 'x' into a string:
!cond(!lt(x,0) : "Negative",
!eq(x,0) : "Zero",
!eq(x,1) : "One,
1 : "MoreThanOne")
Reviewed By: hfinkel, simon_tatham, greened
Differential Revision: https://reviews.llvm.org/D55758
llvm-svn: 352185
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
