Skip to content

Conversation

@aleclearmind
Copy link
Contributor

This commit introduces support for having : and - at the beinning of a YAML scalar. Right now, YAMLParser disallows them if we are in a flow sequence ([ ... ]), but the YAML specification does not seem to hint at this limitation.

This enables us to correctly parse YAML that has gone through other YAML libraries and pyyaml in particular.

tstellar and others added 30 commits January 27, 2021 15:21
(cherry picked from commit 12de8e1)
…ith #ifdef.

These changes are intended to give code a path to move away from the GNU
,##__VA_ARGS__ extension, which is non-conforming in some situations and
which we'd like to disable in our conforming mode in those cases.

(cherry picked from commit 0436ec2)
More study has discovered this to not actually be useful: because
current C++20 implementations reject `#ifdef __VA_OPT__`, this can't
really be used as a feature-test mechanism. And it's not too hard to
detect __VA_OPT__ without this, for example:

  #define THIRD_ARG(a, b, c, ...) c
  #define HAS_VA_OPT(...) THIRD_ARG(__VA_OPT__(,), 1, 0, )
  #if HAS_VA_OPT(?)

Partially reverts 0436ec2.

(cherry picked from commit 5dfa37a)
the changes were reverted.

(cherry picked from commit 727fc31)
…ottom to avoid value changes compared with LLVM<=11

Fixes PR48905

(cherry picked from commit 6612c2b)
…onforming modes"

This reverts commit f453793.
This reverts commit b43c26d.

This GNU and MSVC extension turns out to be very popular. Most projects
are not using C++20, so cannot use the new __VA_OPT__ feature to be
standards conformant. The other workaround, using -std=gnu*, enables too
many language extensions and isn't viable.

Until there is a way for users to get the behavior provided by the
`, ## __VA_ARGS__` extension in the -std=c++17 and earlier language
modes, we need to revert this.

(cherry picked from commit 61a66e4)
The two operations have acted differently since Clang 8, but were
unfortunately mangled the same. The new mangling uses new "vendor
extended expression" syntax proposed in
itanium-cxx-abi/cxx-abi#112

GCC had the same mangling problem, https://gcc.gnu.org/PR88115, and
will hopefully be switching to the same mangling as implemented here.

Additionally, fix the mangling of `__uuidof` to use the new extension
syntax, instead of its previous nonstandard special-case.

Adjusts the demangler accordingly.

Differential Revision: https://reviews.llvm.org/D93922

(cherry picked from commit 9c7aeae)
Previously, we were emitting an extraneous X .. E in <template-arg>
around an <expr-primary> if the template argument was constructed from
an expression (rather than an already-evaluated literal value).  In
such a case, we would then e.g. emit 'XLi0EE' instead of 'Li0E'.

We had one special-case for DeclRefExpr expressions, in particular, to
omit them the mangled-name without the surrounding X/E. However,
unfortunately, that special case also triggered for ParmVarDecl (a
subtype of VarDecl), and _incorrectly_ emitted 'L_Z .. E' instead of
the proper 'Xfp_E'.

This change causes mangleExpression itself to be responsible for
emitting X/E around non-primary expressions, which removes the
special-case, and corrects both these problems.

Differential Revision: https://reviews.llvm.org/D95487

(cherry picked from commit 8ca3360)
The Clang enable_if extension is mangled as an <extended-qualifier>,
which is supposed to contain <template-args>. However, we were
unconditionally emitting X/E around its arguments, neglecting the fact
that <expr-primary> should be emitted directly without the surrounding
X/E.

Differential Revision: https://reviews.llvm.org/D95488

(cherry picked from commit a7246ba)
Also remove main-brancy-sync workflow that was removed from the main branch.
This fixes a bug [[ http://llvm.org/PR48891 | PR48891 ]] introduced in D93839 where:
```
#include <stdint.h>
namespace rep {}
```
got formatted as
```
#include <stdint.h>
namespace rep {
}
```

Reviewed By: MyDeveloperDay, leonardchan

Differential Revision: https://reviews.llvm.org/D95479

(cherry picked from commit e3713f1)
Follow-up to D17444. Fixes PR48904. See bug for details.

Differential Revision: https://reviews.llvm.org/D95559

(cherry picked from commit 764a7a2)
The legacy protocol will be removed on trunk after the 12 branch cut,
and gone in clangd 13.

Differential Revision: https://reviews.llvm.org/D95031

(cherry picked from commit 29472bb)
(ClangTidy configuration block hasn't been in any release, so we should be OK
to move it around like this)

Differential Revision: https://reviews.llvm.org/D95362

(cherry picked from commit c3df9d5)
Replace VLA with dynamic allocation using alloca().
This fixes https://bugs.llvm.org/show_bug.cgi?id=48919.

Differential Revision: https://reviews.llvm.org/D95627

(cherry picked from commit 7f5ad0e)
To make it pass also on 32-bit Windows, see PR48920.

(cherry picked from commit 0024efc)
Before the patch it was possible to trigger a constant bus
violation when folding immediates into a shrunk instruction.

The patch adds a check to enforce the legality of the new operand.

Differential Revision: https://reviews.llvm.org/D95527

(cherry picked from commit fc8e741)
This commit accidentally enabled fgetgrent_r() in the msan tests under
FreeBSD, but this function is not supported. Also remove FreeBSD from
the SANITIZER_INTERCEPT_FGETGRENT_R macro.

(cherry picked from commit e056fc6)
This addresses PR48930.

Differential Revision: https://reviews.llvm.org/D95658

(cherry picked from commit 0217f1c)
LLVMTestingSupport is not part of libLLVM, and therefore can not
be linked to via LLVM_LINK_COMPONENTS.  Instead, it needs to be
specified explicitly to ensure that it is linked explicitly
even if LLVM_LINK_LLVM_DYLIB is used.  This is consistent with handling
in clangd.

Fixes PR#48931

Differential Revision: https://reviews.llvm.org/D95653

(cherry picked from commit 632545e)
…CUDA system

D95466 dropped CUDA to build NVPTX deviceRTL and enabled it by default.
However, the building requires some libraries that are not available on non-CUDA
system by default, which could break the compilation. This patch disabled the
build by default. It can be enabled with `LIBOMPTARGET_BUILD_NVPTX_BCLIB=ON`.

Reviewed By: kparzysz

Differential Revision: https://reviews.llvm.org/D95556

(cherry picked from commit fb12df4)
This patch fixes updating MemorySSA if the header contains memory
defs that do not clobber a duplicated instruction. We need to find the
first defining access outside the loop body and use that as defining
access of the duplicated instruction.

This fixes a crash caused by bee4868.

(Cherry-picked on the 12.x release branch from
10c5726)
…for RTLsTy

From https://bugs.llvm.org/show_bug.cgi?id=48973, we know that
`std::call_once(PM->RTLs.initFlag, &RTLsTy::LoadRTLs, PM->RTLs)` causes compile
time problems in libstdc++v3 5.3.1. This is because there was a defect in the
standard regarding the `call_once` (LWG 2442). This was fixed in libstdc++ soon
thereafter, but there are likely other standard libraries where this will fail.

By matching this function call with the other one, we fix this bug.

Differential Revision: https://reviews.llvm.org/D95769
This reverts commit 53040a9 due to its
bad interaction with select i1 -> and/or i1 transformation.

This fixes:
https://bugs.llvm.org/show_bug.cgi?id=49005
https://bugs.llvm.org/show_bug.cgi?id=48435

(cherry picked from commit 0682903)
pfez and others added 22 commits March 14, 2022 09:13
This commit improves the handling of comparision of a value masked in a
certain way with a constant. For example, for a 16-bit integer, we might
have x & 0xfff0 == 0x1230. This is a typical situation produced by
InstCombine to efficiently check if x is between 0x1230 and 0x12340
(excluded).
Before this patch, LLVM's DominatorTree and related templates
(DominatorTree, DomTreeBuilder) did not support the computation of
dominator and post-dominator trees on graphs with markers, such as
GraphTraits<llvm::Inverse<T>>.
They only supported plain graph traits.

This patch restructures all the necessary templates, adding an
additional template argument (View), which allows to compute DT and PDT
on all the graphs that use GraphTraits, potentially equipped with a
View.
View is a marker, that allows to provide a different view on a graph
that has GraphTraits.
A typical example of this is llvm::Inverse.

This mechanism of View markers will be used in rev.ng to implement
filtered graph traits, to filter the edges of a graph implemented with
GraphTraits.
The new DT and PDT on the marked version of the GraphTraits will be
computed on the same graphs, but treating some edges as if they are seen
through the view.
For instance, the Post-Dominator Tree of a graph marked with
llvm::Inverse view is the Dominator Tree.

The previous default behavior of DT and PDT is implemented by means of
the DTIdentityView, which simply leaves the node type of the GraphTraits
untouched.
This is a transparent view that allows all the code in llvm to continue
working as before this patch.
…emorySSA

A logic incompleteness may lead MemorySSA to be too conservative in its results. Specifically,
when dealing with a call of kind `call i32 bitcast (i1 (i1)* @test to i32 (i32)*)(i32 %1)`,
where function call `test` is declared with `readonly` attribute, the bitcast is not wrapped,
obscuring function attributes. Hence, some methods of CallBase (e.g., `doesNotReadMemory`)
could provide incomplete results. This issue was addressed with improved checks.
Previously we missed cloning metadata on function declarations because
we don't call CloneFunctionInto() on declarations in CloneModule().

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D113812
YAML v1.1 spec interprets more values as booleans than the YAML v1.2
spec. This commit quotes the ambiguous booleans (e.g. "off"). YAML 1.2
parsers will still correctly parse the quoted values, while YAML 1.1
will be able to correctly parse them as strings and not as booleans.

Ref YAML 1.1 spec: https://yaml.org/type/bool.html
This commit introduces support for having `:` and `-` at the beinning of
a YAML scalar. Right now, YAMLParser disallows them if we are in a flow
sequence (`[ ... ]`), but the YAML specification does not seem to hint
at this limitation.

This enables us to correctly parse YAML that has gone through other YAML
libraries and pyyaml in particular.
@pfez
Copy link
Contributor

pfez commented Apr 12, 2022

Can you please add some tests for the additional cases you're supporting?

@aleclearmind
Copy link
Contributor Author

Yup, I need to look into this again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.