| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
|
|
|
|
Instead of passing the Size by reference, assuming it is initialized,
return it alongside the expected char result as a POD.
This makes the interface less error prone: previous interface expected
the Size reference to be initialized, and it was often forgotten,
leading to uninitialized variable usage. This patch fixes the issue.
This also generates faster code, as the returned POD (a char and an
unsigned) fits in 64 bits. The speedup according to compile time tracker
reach -O.7%, with a good number of -0.4%. Details are available on
https://llvm-compile-time-tracker.com/compare.php?from=3fe63f81fcb999681daa11b2890c82fda3aaeef5&to=fc76a9202f737472ecad4d6e0b0bf87a013866f3&stat=instructions:u
And icing on the cake, on my setup it also shaves 2kB out of
libclang-cpp :-)
This is a recommit of d8f5a18b6e587aeaa8b99707e87b652f49b160cd for
|
|
The modules build trips over this frequently because there is no textual
include of the tablegen output, but the module includes it.
Differential revision: https://reviews.llvm.org/D157119
|
|
Platform-specific language extensions often want to provide a way of
indicating that certain functions should be called in a different way,
compiled in a different way, or otherwise treated differently from a
“normal” function. Honoring these indications is often required for
correctness, rather being than an optimization/QoI thing.
If a function declaration has a property P that matters for correctness,
it will be ODR-incompatible with a function that does not have property P.
If a function type has a property P that affects the calling convention,
it will not be two-way compatible with a function type that does not
have property P. These properties therefore affect language semantics.
That in turn means that they cannot be treated as standard [[]]
attributes.
Until now, many of these properties have been specified using GNU-style
attributes instead. GNU attributes have traditionally been more lax
than standard attributes, with many of them having semantic meaning.
Examples include calling conventions and the vector_size attribute.
However, there is a big drawback to using GNU attributes for semantic
information: compilers that don't understand the attributes will
(by default) emit a warning rather than an error. They will go on to
compile the code as though the attributes weren't present, which will
inevitably lead to wrong code in most cases. For users who live
dangerously and disable the warning, this wrong code could even be
generated silently.
A more robust approach would be to specify the properties using
keywords, which older compilers would then reject. Some vendor-specific
extensions have already taken this approach. But traditionally, each
such keyword has been treated as a language extension in its own right.
This has three major drawbacks:
(1) The parsing rules need to be kept up-to-date as the language evolves.
(2) There are often corner cases that similar extensions handle differently.
(3) Each extension requires more custom code than a standard attribute.
The underlying problem for all three is that, unlike for true attributes,
there is no established template that extensions can reuse. The purpose
of this patch series is to try to provide such a template.
One option would have been to pick an existing keyword and do whatever
that keyword does. The problem with that is that most keywords only
apply to specific kinds of types, kinds of decls, etc., and so the
parsing rules are (for good reason) not generally applicable to all
types and decls.
Really, the “only” thing wrong with using standard attributes is that
standard attributes cannot affect semantics. In all other respects
they provide exactly what we need: a well-defined grammar that evolves
with the language, clear rules about what an attribute appertains to,
and so on.
This series therefore adds keyword “attributes” that can appear
exactly where a standard attribute can appear and that appertain
to exactly what a standard attribute would appertain to. The link is
mechanical and no opt-outs or variations are allowed. This should
make the keywords predictable for programmers who are already
familiar with standard attributes.
This does mean that these keywords will be accepted for parsing purposes
in many more places than necessary. Inappropriate uses will then be
diagnosed during semantic analysis. However, the compiler would need
to reject the keywords in those positions whatever happens, and treating
them as ostensible attributes shouldn't be any worse than the alternative.
In some cases it might even be better. For example, SME's
__arm_streaming attribute would make conceptual sense as a statement
attribute, so someone who takes a “try-it-and-see” approach might write:
__arm_streaming { …block-of-code…; }
In fact, we did consider supporting this originally. The reason for
rejecting it was that it was too difficult to implement, rather than
because it didn't make conceptual sense.
One slight disadvantage of the keyword-based approach is that it isn't
possible to use #pragma clang attribute with the keywords. Perhaps we
could add support for that in future, if it turns out to be useful.
For want of a better term, I've called the new attributes "regular"
keyword attributes (in the sense that their parsing is regular wrt
standard attributes), as opposed to "custom" keyword attributes that
have their own parsing rules.
This patch adds the Attr.td support for regular keyword attributes.
Adding an attribute with a RegularKeyword spelling causes tablegen
to define the associated tokens and to record that attributes created
with that syntax are regular keyword attributes rather than custom
keyword attributes.
A follow-on patch contains the main Parse and Sema support,
which is enabled automatically by the Attr.td definition.
Other notes:
* The series does not allow regular keyword attributes to take
arguments, but this could be added in future.
* I wondered about trying to use tablegen for
TypePrinter::printAttributedAfter too, but decided against it.
RegularKeyword is really a spelling-level classification rather
than an attribute-level classification, and in general, an attribute
could have both GNU and RegularKeyword spellings. In contrast,
printAttributedAfter is only given the attribute kind and the type
that results from applying the attribute. AFAIK, it doesn't have
access to the original attribute spelling. This means that some
attribute-specific or type-specific knowledge might be needed
to print the attribute in the best way.
* Generating the tokens automatically from Attr.td means that
pseudo's libgrammar does now depend on tablegen.
* The patch uses the SME __arm_streaming attribute as an example
for testing purposes. The attribute does not do anything at this
stage. Later SME-specific patches will add proper semantics for it,
and add other SME-related keyword attributes.
Differential Revision: https://reviews.llvm.org/D148700
|
|
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
|
|
|
|
This avoids having to specify the location of all individual tools.
In current builds, one may want to specify LLVM_TABLEGEN, CLANG_TABLEGEN,
LLDB_TABLEGEN, LLVM_CONFIG_PATH, CLANG_PSEUDO_GEN and
CLANG_TIDY_CONFUSABLE_CHARS_GEN; specifying just the base directory
containing all of them is much more convenient.
Factorize the code for setting up use of a tool that is used during
the build (which either is newly built in the same build, or
built in a separate nested cmake build - when cross compiling or
when e.g. optimized tablegen is requested - or used from an existing
prebuilt binary).
Differential Revision: https://reviews.llvm.org/D131052
|
|
Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the
same for `makeMutableArrayRef`.
Once all of the places in-tree are using the deduction guides for
`MutableArrayRef`, we can mark `makeMutableArrayRef` as deprecated.
Differential Revision: https://reviews.llvm.org/D141814
|
|
The Annotations helper class does not have a gtest or gmock dependency, but because it's bundled with the rest of TestingSupport, it gets one. By splitting it out, a target can use it without being forced to use LLVM's copy of gtest.
Reviewed By: GMNGeoffrey, sammccall, gribozavr2
Differential Revision: https://reviews.llvm.org/D141175
|
|
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
|
|
This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
Change a few functions (getCheckTraversalKind, some clang/Tooling/ API, etc)
from llvm::Optional to std::optional.
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
These source files no longer use None, so they do not need to include
None.h.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
Since std::optional does not offer getPointer(), this patch replaces
X.getPointer() with &*X to make the migration from llvm::Optional to
std::optional easier.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Differential Revision: https://reviews.llvm.org/D138466
|
|
Need to take a break from this, so write down where we got to.
Differential Revision: https://reviews.llvm.org/D135696
|
|
Set CLANG_NO_DEFAULT_CONFIG=1 for clang-tools-extra tests to prevent
the system configuration files for clang from affecting the test
results.
Differential Revision: https://reviews.llvm.org/D135159
|
|
|
|
Identified with modernize-unary-static-assert.
|
|
Mostly mechanics here. Interesting decisions:
- apply disambiguation in-place instead of copying the forest
debatable, but even the final tree size is significant
- split decide/apply into different functions - this allows the hard part
(decide) to be tested non-destructively and combined with HTML forest easily
- add non-const accessors to forest to enable apply
- unit tests but no lit tests: my plan is to test actual C++ disambiguation
heuristics with lit, generic disambiguation mechanics without the C++ grammar
Differential Revision: https://reviews.llvm.org/D132487
|
|
Using the guard to implement part of the rule https://eel.is/c++draft/dcl.pre#6.
```
void foo() {
// can be parsed as
// - structured-binding declaration (a false parse)
// - assignment expression
array[index] = value;
}
```
Differential Revision: https://reviews.llvm.org/D132260
|
|
The bug was that if we recover from the token 0, we will make the
Heads empty (Line646), which results no recovery being applied.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D132388
|
|
Previously we were calling glrRecover() ad-hoc at the end of input.
Two main problems with this:
- glrRecover() on two separate code paths is inelegant
- We may have to recover several times in succession (e.g. to exit from
nested scopes), so we need a loop at end-of-file
Having an actual shift action for an EOF terminal allows us to handle
both concerns in the main shift/recover/reduce loop.
This revealed a recovery design bug where recovery could enter a loop by
repeatedly choosing the same parent to identically recover from.
Addressed this by allowing each node to be used as a recovery base once.
Differential Revision: https://reviews.llvm.org/D130550
|
|
|
|
|
|
Our GLR uses lookahead: only perform reductions that might be consumed by the
shift immediately following. However when shift fails and so reduce is followed
by recovery instead, this restriction is incorrect and leads to missing heads.
In turn this means certain recovery strategies can't be made to work. e.g.
```
ns := NAMESPACE { namespace-body } [recover=Skip]
ns-body := namespace_opt
```
When `namespace { namespace {` is parsed, we can recover the inner `ns` (using
the `Skip` strategy to ignore the missing `}`). However this `namespace` will
not be reduced to a `namespace-body` as EOF is not in the follow-set, and so we
are unable to recover the outer `ns`.
This patch fixes this by tracking which heads were produced by constrained
reduce, and discarding and rebuilding them before performing recovery.
This is a prerequisite for the `Skip` strategy mentioned above, though there are
some other limitations we need to address too.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D130523
|
|
See https://reviews.llvm.org/D130626 for motivation.
Identifier in the grammar has different categories (type-name, template-name,
namespace-name), they requires semantic information to resolve. This patch is
to eliminate the "local" ambiguities in type-name, and namespace-name, which
gives us a performance boost of the parser:
- eliminate all different type rules (class-name, enum-name, typedef-name), and
fold them into a unified type-name, this removes the #1 type-name ambiguity, and
gives us a big performance boost;
- remove the namespace-alis rules, as they're hard and uninteresting;
Note that we could eliminate more and gain more performance (like fold template-name,
type-name, namespace together), but at current stage, we'd like keep all existing
categories of the identifier (as they might assist in correlated disambiguation &
keep the representation of important concepts uniform).
| file |ambiguous nodes | forest size | glrParse performance |
|SemaCodeComplete.cpp| 11k -> 5.7K | 10.4MB -> 7.9MB | 7.1MB/s -> 9.98MB/s |
| AST.cpp | 1.3k -> 0.73K | 0.99MB -> 0.77MB | 6.7MB/s -> 8.4MB/s |
Differential Revision: https://reviews.llvm.org/D130747
|
|
|
|
|
|
A followup patch of d489b3807f096584175c321ce7f20e9dcd49b1da, but for
member functions, this will eliminate a false parse of member
declaration.
Differential Revision: https://reviews.llvm.org/D131720
|
|
We happened to introduce a `member-declaration := ;` rule
when inlining the `member-declaration := decl-specifier-seq_opt
member-declarator-list_opt ;`.
And with the `member-declaration := empty-declaration` rule, we had two parses of `;`.
This patch is to restrict the grammar to eliminate the
`member-declaration := ;` rule.
Differential Revision: https://reviews.llvm.org/D131724
|
|
Differential Revision: https://reviews.llvm.org/D131396
|
|
|
|
It should be `sizeof(*this)`.
|
|
Now that we've updated to C++17 MSVC gives very verbose warnings about not creating classes that inherit from std::iterator - use llvm::iterator_facade_base instead
Fixes #57005
|
|
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D130826
|
|
|
|
The solution is to favor the longest possible nest-name-specifier, and
drop other alternatives by using the guard, per per C++ [basic.lookup.qual.general].
Motivated cases:
```
Foo::Foo() {};
// the constructor can be parsed as:
// - Foo ::Foo(); // where the first Foo is return-type, and ::Foo is the function declarator
// + Foo::Foo(); // where Foo::Foo is the function declarator
```
```
void test() {
// a very slow parsing case when there are many qualifers!
X::Y::Z;
// The statement can be parsed as:
// - X ::Y::Z; // ::Y::Z is the declarator
// - X::Y ::Z; // ::Z is the declarator
// + X::Y::Z; // a declaration without declarator (X::Y::Z is decl-specifier-seq)
// + X::Y::Z; // a qualifed-id expression
}
```
Differential Revision: https://reviews.llvm.org/D130511
|
|
Apparently new string[/*no size*/]{"foo", "bar"} is a clang/gcc extension?
|
|
|
|
This was an earlier draft of Language.h that got committed accidentally
|
|
- Place rules under rule::lhs::rhs__rhs__rhs
- Change mangling of keywords to ALL_CAPS (needed to turn keywords that appear
alone on RHS into valid identifiers)
- Make enums implicitly convertible to underlying type (though still scoped,
using alias tricks)
In principle this lets us exhaustively write a switch over all rules of a NT:
switch ((rule::declarator)N->rule()) {
case rule::declarator::noptr_declarator:
...
}
In practice we don't do this anywhere yet as we're often switching over multiple
nonterminal kinds at once.
Differential Revision: https://reviews.llvm.org/D130414
|
