-
Notifications
You must be signed in to change notification settings - Fork 13
YAMLParser: allow : and - at plain scalar start #12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
aleclearmind
wants to merge
244
commits into
revng:master
Choose a base branch
from
aleclearmind:feature/fix-yaml-scalar
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(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)
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.
|
Can you please add some tests for the additional cases you're supporting? |
|
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.