This makes it slightly harder to misuse Twines. It is still possible to
refer to destroyed temporaries with the regular constructors, though.
Patch by Marco Alesiani!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209832 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted in r208642 due to regressions surrounding file changes
within lexical scopes causing inlining information to be lost.
The issue was in LexicalScopes::getOrCreateInlinedScope, where I was
previously testing "isLexicalBlock" which is false for
"DILexicalBlockFile" (a scope used to represent changes in the current
file name) and assuming it was then a function (breaking out of the
inlined scope path and reaching for the parent non-inlined scopes). By
inverting the condition and testing for "isSubprogram" the correct
behavior is attained.
(also found some weirdness in Clang, see r208742 when reducing this test
case - the resulting test case doesn't apply with the Clang fix, but
I've added a more realistic test case to inline-scopes.ll which does
reproduce the issue and demonstrate the fix)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208748 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r208506.
Some inlined subroutine scopes appear to be missing with this change.
Reverting while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208642 91177308-0d34-0410-b5e6-96231b3b80d8
This behavior was added to support StringMaps of StringMaps, default +
move construction are sufficient for this.
Real move construction support coming soon (& probably copy construction
too).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208360 91177308-0d34-0410-b5e6-96231b3b80d8
When we were moving from a larger vector to a smaller one but didn't
need to re-allocate, we would move-assign over uninitialized memory in
the target, then move-construct that same data again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207663 91177308-0d34-0410-b5e6-96231b3b80d8
wrong iterator category. These aren't comprehensive, but they have
caught the common cases for me and produce much nicer errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207601 91177308-0d34-0410-b5e6-96231b3b80d8
requiring full control over the various parameters to the std::iterator
concept / trait thing. This is a precursor for adjusting these things to
where you can write a bidirectional iterator wrapping a random access
iterator with custom increment and decrement logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207487 91177308-0d34-0410-b5e6-96231b3b80d8
Actually use the `reference` typedef, and remove the private
redefinition of `pointer` since it has no users.
Using `reference` exposes a problem with r207257, which specified the
wrong `value_type` to `iterator_facade_base` (fixed that too).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207270 91177308-0d34-0410-b5e6-96231b3b80d8
Use the fancy new `iterator_facade_base` to add
`scc_iterator::operator->()`. Remove other definitions where
`iterator_facade_base` does the right thing.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207257 91177308-0d34-0410-b5e6-96231b3b80d8
These are long functions that really shouldn't be inlined. Otherwise,
no functionality change.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207249 91177308-0d34-0410-b5e6-96231b3b80d8
Functions declared in line in a class are inlined by default. There's
no reason for the `inline` keyword.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207248 91177308-0d34-0410-b5e6-96231b3b80d8
own CRTP base class for more general purpose use. Add some clarifying
comments for the exact way in which the adaptor uses it. Hopefully this
will help us write increasingly full featured iterators. This is
becoming important as they start to be used heavily inside of ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207072 91177308-0d34-0410-b5e6-96231b3b80d8
Boost's iterator_adaptor, and a specific adaptor which iterates over
pointees when wrapped around an iterator over pointers.
This is the result of a long discussion on IRC with Duncan Smith, Dave
Blaikie, Richard Smith, and myself. Essentially, I could use some subset
of the iterator facade facilities often used from Boost, and everyone
seemed interested in having the functionality in a reasonably generic
form. I've tried to strike a balance between the pragmatism and the
established Boost design. The primary differences are:
1) Delegating to the standard iterator interface names rather than
special names that then make up a second iterator-like API.
2) Using the name 'pointee_iterator' which seems more clear than
'indirect_iterator'. The whole business of calling the '*p' operation
'pointer indirection' in the standard is ... quite confusing. And
'dereference' is no better of a term for moving from a pointer to
a reference.
Hoping Duncan, and others continue to provide comments on this until
we've got a nice, minimal abstraction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207069 91177308-0d34-0410-b5e6-96231b3b80d8
r206916 was not logically the same as the previous code because the
goto statements did not create loop. This should be the same as the
previous code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206918 91177308-0d34-0410-b5e6-96231b3b80d8
Goto statements jumping into previous inner blocks are pretty confusing
to read even though in this case they are valid. No reason to not use
while loops there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206916 91177308-0d34-0410-b5e6-96231b3b80d8
This warning is disabled for the LLVM build,
but external users of the header can still
run into this.
Patch by Ke Bai
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206629 91177308-0d34-0410-b5e6-96231b3b80d8
Doesn't make sense to restrict this to BumpPtrAllocator. While there
replace an explicit loop with std::equal. Some standard libraries know
how to compile this down to a ::memcmp call if possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206615 91177308-0d34-0410-b5e6-96231b3b80d8
allocation libraries, may allow more efficient allocation and
deallocation. It at least makes the interface implementable by the JIT
memory manager.
However, this highlights problematic overloading between the void* and
the T* deallocation functions. I'm looking into a better way to do this,
but as it happens, it comes up rarely in the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206265 91177308-0d34-0410-b5e6-96231b3b80d8
