EvalFunctionCall.fImplicitThis is sometimes redundant in that the
owner evaluation is already stored by one of the arguments. In
such cases, storing the owner separately in fImplicitThis can lead
to exponential complexity in chained method calls.
We resolve the duplication by computing the implicit this from the
function name evaluation instead of storing it where possible.
This was already implemented for cases where the function name
evaluation is an EvalMemberAccess in commit 659ff8c4a7. This
commit extends the approach to cases where the function name
evaluation is an EvalID.
Change-Id: Ic71e81b4692c51ffb8e15b3da9fc2dff1a554f05
When a subsequent regular (non-friend) declaration of such a class
is indexed, the index binding needs to be marked as being fully
visible to name lookup.
Change-Id: I1a625f93eda1af257a9af50b5c4f115fc9bf6526
The first patch for bug 527697 made us not instantiate such an
argument, because determinePackSize() would return PACK_SIZE_DEFER.
The motivation for that fix was to avoid sizeof...(T) prematurely
instantiating to a concrete value in cases where T was mapped to
a pack expansion.
This patch reverts the change to determinePackSize() and applies a
different fix for the sizeof...(T), specific to EvalUnaryTypeId.
Change-Id: Idc231aeecb5d50e93dda364c6d2deb08057cc8b6
This avoids expontential complexity when type template arguments inside
an ambiguous name specifier themselves contain ambiguous name specifiers.
The patch also enhances TemplateIdStrategy to allow marking and backing
up to a branch point, and uses this ability in templateArgument().
Change-Id: Ia03e9cd0bc026b02b85edc05ed327cce883d6a59
The special binding type CPPLambdaExpressionParameter is removed.
Instead, a lambda expression parameters's are represented as
regular CPPParameters owned by the closure type's generated
function call operator.
Change-Id: I4afeac90c2595a1f84dfa59f057d0494b64d079c
The pseudo-destructor is represented as a CPPImplicitFunction, computed
lazily and stored by CPPBasicType.
This commit also adds support for alias templates to
CPPTemplates.getTemplateName().
Change-Id: I6774556b2493cb68d32c3007d6ce48c7805595f4
Previously, we would only try the first base class whose primary
template matched that of the parameter type.
Change-Id: I0511e6a1ba1c7197887ff23bc37b70a2a820eb87
The evaluated type of 'decltype(auto)' in combination with const and/or
volatile will be a ProblemType since this is not valid code. The patch
also contains a checker to give the user a visual feedback.
Note: A proposed quick-fix has been removed after a short discussion.
Change-Id: I8760ed0ac28e28529ab30516accac9c0413c87d9
Signed-off-by: Hansruedi Patzen <hansruedi.patzen@hsr.ch>
The previous implementation deviated from the C++ standard by checking
that the types of the return expressions are the same, rather than the
return types after deduction against the placeholder type.
There was also a bug in the return type deduction code for lambdas,
where for a lambda without an explicit placeholder in the trailing-
return-type, the deduction process wouldn't be performed.
Change-Id: I2f0b9f1c7778aef60e4cd7ada9386b99be52669a
The computation had a bug where the array decayed to a pointer, and we
tried to use the pointer's value as a composite value, instead of the
underlying array's value.
Change-Id: I9510d28e04deb0b8ef835e2857f8b513d11d1d72
InstantiationContext.setExpandPack() and related methods were introduced
in bug 486971 to ensure that when instantiating a type list that
contains a pack expansion, with a parameter map that maps the template
parameter pack that appears in the expansion to another parameter pack
(which can happen when e.g. instantiating an alias template with
dependent arguments), the pack is expanded in the correct place.
However, bug 486971 only added use of this machinery to CPPTemplates.
instantiateArguments(). We can also instantiate a type list in
instantiateTypes() (used e.g. when instantiating the parameter types
of a function type), so the machinery needs to be used there as well.
Change-Id: Iabb458e8e3166c15ed922656fc0729a4a8cf8bbf
- add IOptionalBuildObjectPropertiesContainer interface to use for
objects that supply optional build properties
- add new IOptionalBuildProperties interface that defines
optional build properties donated by external plug-ins
- add new
- change IConfiguration to an IOptionalBuildObjectPropertiesContainer
- change IManagedProject to be an
IOptionalBuildObjectPropertiesContainer
- fix ProcessClosure to ensure that readers are not null before
accessing them
- fix Container launch delegate to look at project optional
build properties for active configuration to fetch connection
and image info and use said info to find a matching
launch or create a new one
- have Container launch delegate use the image name as part of
the launch config name
- have Container launch short-cut also use the project's
optional build properties for the active config to get
connection and image information before any defaulting
- change AutotoolsNewMarkerGenerator to store the command
launcher as an ICommandLauncher
- add new CommandLauncherFactory extension to cdt.core that
allows plug-ins to specify a CommandLauncherFactory that
will return an ICommandLauncher based on the project
- add macros for new extension to CCorePlugin
- add new CommandLauncherManager class that loads
CommandLauncherFactory extensions and is used to give
an ICommandLauncher wrapper that will go through the list
of CommandLauncherFactory extensions until one returns
non-null ICommandLauncher
- add code to RemoteCommandLauncher so it will use the
CommandLauncherManager to get the local launcher
- also change RemoteCommandLauncher to check at execution
time whether the command is local and in that case use
the local command launcher
- add new ICommandLauncherFactory interface
- add new ContainerCommandLauncher to launch
- add new ContainerCommandLauncherFactory class for returning
a ContainerCommandLauncher instance to launch commands
in a Docker Container
- change MakeBuilder to use CommandLauncherManager to get
its ICommandLauncher
- change CommandBuilder to use CommandLauncherManager too
- ditto for Builder and AbstractBuiltinSpecsDetector and
ExternalToolInvoker
- change Configuration to load/store optional build properties
as well as return the properties to get/set
- ditto for MultiConfiguration
- change ManagedProject to implement IOptionalBuildOptionProperties
interface
- ditto for ProjectType
- create new OptionalBuildProperties class to store optional
build properties for a configuration
- bump cdt.docker.launcher to 1.1.0
- use CommandLauncherFactory extension to define
ContainerCommandLauncherFactory
- add optional ContainerPropertyTab which allows the end-user to
optionally choose to build a C/C++ project in a Container
and specify the connection/image to use
- in LanguageSettingsSerializableSettings class, call the
CommandLauncherManager getLanguageSettingEntries method
to get the massaged language setting entries based on the
current list
- in LanguageSettingsProviderSerializer, try and get the
pooled entries using the cfg description so that it will
have the project and can use the CommandLauncherManager
to get entries from image
- in ContainerCommandLauncherFactory move cached headers under
a HEADERS directory in the plug-in area
- create a sub-directory for the connection and a sub-directory
for the image based on cleansed names
- store the real names of the connection and image to use
later in the DockerHeaderPreferencePage
- modify LanguageSettingsEntriesTab to force the horizontal
scroll bar to appear (this is a bug in SWT SashForm support
and the fix here isn't quite correct, but is better)
- add new DockerHeaderPreferencePage that allows user to
remove cached headers from images
- change C/C++ Docker preferences to be titled: Docker Container
- fix LanguageSettingsWorkspaceProvider.getSettingEntries method
to use the CommandLauncherManager so entries will be transformed
to use cached headers
- add BaseDatabindingModel class
- add DataVolumeModel class to model a volume mount
- add ContainerPropertyVolumes model to model volume specification
and selected volumes
- add properties to ContainerCommandLauncher to represent
volumes and selected volumes for a configuration
- add ContainerDataVolumeDialog for specifying a volume
mount by the end-user
- add a null detector for cfgDescription in
LanguageSettingsSerializableProvider
- fix AutotoolsNewMakeGenerator.getWinOSType to not specify "." for
working dir
- fix GCCBuiltinSpecsDetectorCygwin to not map paths to Cygwin if
the current configuration is enabled for container build
- add logic to ContainerCommandLauncher to look for Windows
file formats and change them to unix format and map
any "." working dir to be /tmp
- fix ContainerLauncherConfigurationDelegate similarly
- fix AbstractBuiltinSpecsDetector to pass in the current
configuration description when getting the CommandLauncher
since the current configuration may not be the active
configuration
- change ContainerPropertyTab to add Elf and GNU Elf binary parsers
when build in Container is chosen so that output executables
are treated as Binaries by the CDT project
- add documentationl for the ContainerPropertyTab in Build Settings and
the Data Volume dialog pop-up it brings up
- change CommandBuilder to accept a project as an argument
to its constructor and to pass this as an argument to
the CommandLauncherManager
- have StepBuilder pass project when creating a CommandBuilder
Change-Id: Ia78488b93056e6ec7ca83a6c87b3a9d2b9424943
This ensures that name resolution can proceed when a TypeOfUnknownMember
appears on the left hand side of a scope resolution operator.
Change-Id: I2dfc22eb474b8a2f776eda09ce90c91462d7fe5b
This is a revised approach for fixing this bug by giving using-
declarations implicit names for each delegate binding.
Change-Id: Ib9695c30258b8cb322ae1548ab022e357318135c
Previously, such filtering was only done in resolveAmbiguities(),
which was too late for name lookup for proceed to an enclosing
scope if it did not find valid candidates in the namespace scope.
Change-Id: I435d7be1aff5344985c1bbb201bf5d383d43fe8d
This fixes a couple of places where a call to
PDOM.acquireWriteLock() is not paired with a call to
releaseWriteLock() in a finally block.
Change-Id: I45a8bd9a2f6585bb4c4bc1f726fea6f9eba5fb43
Previously, the decl-specifier was used as the key, but a decl-specifier
can be shared by multiple declarators, so seeing the same decl-specifier
against doesn't necessarily mean we have infinite recursion.
Change-Id: I165088c5379d412d1c31f2655c20a02629fbe596
- Change parser to include virtual specifier in function declarator
location
- Change DeclaratorWriter to write all virtual specifiers in their
initial order
Change-Id: Iff381394b834146c1b63877bc9eb84517d31e078
Besides the UX advantages of typedef preservation (such as refactorings
preserving typedefs), it's important for correctness because the
arguments of template aliases can be subject to SFINAE even if they
don't participate in the target type.
Change-Id: I4e71372553dc418d1b8c3e27bd2c0387a41a3269
