declarator. Here, we can only see a few things (e.g., cvr-qualifiers,
nested name specifiers) and we do not want to provide other non-macro
completions. Previously, we would end up in recovery mode and would
provide a large number of non-relevant completions.
llvm-svn: 111818
constructors. We perform semantic checking when creating the definition, and
this isn't needed in certain contexts (value initialization) but is in others
(default initialization). This fixes PR7948.
We add explicit code to the default initialization path to ensure the
definition is both present and valid.
Doug, please review. I think this follows your latest suggestion, and it ended
up remarkably cleaner than I anticipated. Also let me know if similar logic
should be followed for destructors and copy-constructors.
llvm-svn: 111802
That revision started classifying truly empty structs like "Y" and "X"
as being NoClass/NoClass and turning them into 'ignore'. The call code
turns around and allocates space for the ignored argument with
GetUndefRValue. The bug is that GetUndefRValue would return the address
as undef, instead of returning an object with a defined address but
undefined contents.
llvm-svn: 111794
class; they should just be completely opaque throughout IR gen now,
although I haven't really audited that.
Fix a bug apparently inherited from gcc-4.2 where we failed to null-check
member data pointers when performing derived-to-base or base-to-derived
conversions on them.
llvm-svn: 111789
Make CGT defer to the ABI on all member pointer types.
This requires giving CGT a handle to the ABI.
It's way easier to make that work if we avoid lazily creating the ABI.
Make it so.
llvm-svn: 111786
implicitly-defined default constructor, zero-initialize the memory
before calling the default constructor. Previously, we would only
zero-initialize in the case of a trivial default constructor.
Also, simplify the hideous logic that determines when we have a
trivial default constructor and, therefore, don't need to emit any
call at all.
llvm-svn: 111779
pointers. I find the resulting code to be substantially cleaner, and it
makes it very easy to use the same APIs for data member pointers (which I have
conscientiously avoided here), and it avoids a plethora of potential
inefficiencies due to excessive memory copying, but we'll have to see if it
actually works.
llvm-svn: 111776
duplication between the constant and non-constant paths in all of this.
Implement ARM ABI semantics for member pointer constants and conversion.
llvm-svn: 111772
When including a PCH and later re-emitting to another PCH, the name lookup tables of DeclContexts
may be incomplete, since we now lazily deserialize the visible decls of a particular name.
Fix the issue by iterating over the un-deserialized visible decls and completing the lookup tables
of DeclContexts before writing them out.
llvm-svn: 111698
trivial default constructors. We're weren't zero-initializing them,
which manifested as <rdar://problem/8320532> (a regression in the GCC
test suite) and is likely to have caused significant other breakage.
llvm-svn: 111650
sure to (1) actually use the remapped files we were given rather
than old data, and (2) keep the remapped files alive until the
code-completion results are destroyed. Big thanks to Daniel for the
test case.
llvm-svn: 111597
and reenable crash recovery test.
- Reparsing is still very crashy / weird, so I had to sprinkle random code into
the remapped input to get it to do what I want (i.e., crash!).
llvm-svn: 111550
conversion a second time for a conversion candidate (with the real
acting context), because the only problems we would find are access or
ambiguity issues that won't be diagnosed until we pick this
candidate. Add a test case to prove it to myself.
llvm-svn: 111526
conversion functions as if their acting context were the class that
we're converting from (the implicit object argument's
type). Retroactively tweaking the implicit conversion sequence, as we
were trying to do before, breaks the invariants of that implicit
conversion sequence (e.g., the types and conversions don't match
up). Fixes <rdar://problem/8018274>.
llvm-svn: 111520
for incomplete enum types. An incomplete enum can't really be treated as
an "integral or enumeration" type, and the incorrect treatment leads to
bad behavior for many callers.
This makes isIntegralOrEnumerationType equivalent to isIntegerType; I think
we should globally replace the latter with the former; thoughts?
llvm-svn: 111512
Fariborz Jahanian