Use the toolchain type and id as the key to the Map holding the
toolchain files instead of the Path to the file. Also simplifies the
build config since we can always figure out the toolchain file from
the toolchain. Deprecate getting toolchain by path since that shouldn't
be needed any more.
Also took the opportunity to add javadoc to the interfaces.
Change-Id: I11ae2ad8177a3f60399742c8c19576f85ea4b8c0
Because of the missing getRecordSize implementations, subclasses would
starting writing in records that were thought to be malloc'ed by
the parent but it was instead writing in other blocks, possible used
by other PDOM objects or free blocks to be used later and now not initialized
to 0.
This could lead to a few different exceptions like
- BufferUnderflowException(Chunk.getChars)
- CoreException: Corrupted database
- ArrayIndexOutOfBoundsException(AbstractIndexerTask$IndexFileContent.merge)
and possibly others.
Change-Id: Ie6d1986a22a9fb5f5e90cb741046d098ebf10a90
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
README:
Create a C/C++ Application launch as normal, and in the Launch
Configuration dialog click "Select other..." at the bottom/center
and selecting GDB (DAP) Debug Process Launcher
(you can't do this in the LaunchBar's dialog as it does not support
changing the launcher).
Then debug as you normally do (with less features so far :-)
Change-Id: Ia36acedf064b3774c6ac2a863880eaf7efe9c399
When DSF was first created it was a separate project that borrowed
heavily from CDT, as such (AFAICT) some code was copied from
o.e.cdt.launch to DSF. This commit de-duplicates some of that code
as the DAP implementation wants to reuse the code too and another
copy is not wanted.
Change-Id: Ie54187dabc9c32224575c0bf51bcabfab00ca340
We need a way to alert the user that we are unable to find a toolchain
that maps to the current target. An ErrorBuildConfiguration is created
that simply prints out an error message at build time to handle this.
We then set one of these as the active build config in the tracker
with the appropriate message.
We also add a target listener so that when a target becomes OK_STATUS,
we run the tracker again to see if we have the right active build
config for that target. Some targets can only determine some of their
attributes when connected.
Hook up the IToolChain matches so we're using it in the toolchain
manager. This allows toolchains to do more complicated matching of
the properties.
Change-Id: Icaff85117e8147cd2793f2915fa75ce33673ab52
This change adds a few more macro to define things that are supposed to
be built-in in MSVC. Eventually we might want to move some of those to
the parser but it's not clear to me if we want to polute the GCC parser
with all of this.
Change-Id: I6672d8f14470115aa37a0d76b2b4fb086fe4494f
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Add existing type-traits that were implemented for GCC that are relevant to
MSVC. Some are missing but even with those parsing is improved with minimal
effort. For the LLVM codebase, I see it go from 0.46% unresolved names (16,668)
to 0.19% (6,950).
This is combined with another patch that adds temporary macro hacks.
Change-Id: I441dcfa4a986edef78b75c0d6db04b78fdbc97b3
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
While a literal expression itself will never be negative (the negative
sign is parsed as a unary operator), we also use FloatingPointValue to
represent results during value computations which can be negative.
Change-Id: I16227b2d19256066b094ae60476e124b4bcea14d
Add missing ; to test case.
Change-Id: If0224c4fc3580cbe527efe0d3a5739896a000d7e
Signed-off-by: Felix Morgner <fmorgner@hsr.ch>
Signed-off-by: Thomas Corbat <tcorbat@hsr.ch>
Recognize MinGW installations by checking the path of gcc.exe for
substring "ming".
Change-Id: Ibc6d4b03ef715036176e3aea6382dd986e4caae8
Signed-off-by: Thomas Corbat <tcorbat@hsr.ch>
This new Language Settings Provider allows parsing MSVC (cl.exe) compilation
commands, It is done similarly to the GCC Build Output Parser.
It is not enabled by default but can be enabled when in the context of
building with an external builder.
In general, MSVC support still needs some work but this output parser greatly
facilitates setup for certain types of projects.
Change-Id: I3fb110ecdfbac1cabbc16239ad6667a5e628d443
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Problem:
========
Common builder invokes the build on all the referenced projects. For the
markers creation, the project on which build is invoked by user is used,
that is incorrect. Once all the referenced projects are built, the
actual project starts building and removes all the markers associated
with it, hence the markers created previously for referenced projects
are removed and now clicking on error/warning in build console of
referenced projects will not open source file because of missing
markers.
Fix:
====
Always set the correct project being built for markers creation using
setCurrentProject(..) API.
Change-Id: Ief051ac664ea964816fdcbe7f2f54bcf43caa212
Signed-off-by: Umair Sair <umair_sair@hotmail.com>
Problem:
========
filterConfigsToBuild(..) always filters the configs that are once added
to set irrespective if it has been built or not. Consider scenario where
there are three project a, b, c and a depends on b & c and b depends on
c. When a is built, filterConfigsToBuild(..) returns configs of b and c.
Then b starts building and filterConfigsToBuild(..) doesn't return
config of c because its already in set. This is wrong and it should
return config of c because it is not yet built and b depends on it.
Fix:
====
If a referenced config by any project/config is not yet built,
filterConfigsToBuild(..) shouldn't filter it.
Change-Id: I5fbe77789f14ce3114200998070a7461069c98ab
Signed-off-by: Umair Sair <umair_sair@hotmail.com>
The version of the plug-in had been correctly bumped already, but
the tags were missing causing API errors
Change-Id: Ief9f7250d3940c1ddd4d44ee19d53dc99f1af8b5
