IssueTracker

Repro steps I did:
(1) Create a new project
(2) Replace contents of native-app.cpp with content of androidStudioBugs.cpp
(3) Remove references to jni function in MainActivity.java
(4) Build projects.
I get the output pasted below which looks correct to me. Could you supply more repro information?

/usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:7:23: error: non-aggregate type 'map<std::string, char>' (aka 'map<basic_string<char>, char>') cannot be initialized with an initializer list
      map<string, char> mapIterable = {{"foo", 'x'},
                        ^             ~~~~~~~~~~~~~~
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:11:10: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
      for (auto mapEntry : mapIterable) {
           ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:11:24: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
      for (auto mapEntry : mapIterable) {
                         ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:17:5: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
      auto uptr = make_unique<string>();
      ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:17:17: error: use of undeclared identifier 'make_unique'
      auto uptr = make_unique<string>();
                  ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:17:29: error: unexpected type name 'string': expected expression
      auto uptr = make_unique<string>();
                              ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:17:37: error: expected expression
      auto uptr = make_unique<string>();
                                      ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:20:5: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
      auto sptr = make_shared<string>();
      ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:20:17: error: use of undeclared identifier 'make_shared'
      auto sptr = make_shared<string>();
                  ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:20:29: error: unexpected type name 'string': expected expression
      auto sptr = make_shared<string>();
                              ^
  /usr/local/google/home/jomof/AndroidStudioProjects/MyApplication13/app/src/main/cpp/native-lib.cpp:20:37: error: expected expression
      auto sptr = make_shared<string>();

Thank you for looking into this issue. It seems that some of the compilation errors are due to the missing line `using namespace std;` in the file (though the `std::` prefix can also be prepended to each string, make_unique, and other STL functions and types to fix compilation as well). Also, compiling with the cpp flag `-std=c++14` should also remove any warnings of "auto type specifier" and "use of undeclared identifier make_unique".

I've attached an updated cpp file with each STL function prepended with `std::`, as well as a screenshot of Android Studio displaying both the iterable and unique_ptr errors incorrectly reported.

I was able to compile this file

#include <map>
#include <iostream>
#include <memory>  // Note this include

void exampleMapIterable() {
    std::map<std::string, char> mapIterable = {{"foo", 'x'}, {"bar", 'y'}};

    // Android Studio incorrectly reports error for mapIterable: "'map<string, char>' is not a valid range type"
    for (auto mapEntry : mapIterable) {
        std::cout << "{" << mapEntry.first << ": " << mapEntry.second << "}\n";
    }
}

void exampleUniquePtr() {
    auto uptr = std::make_unique<std::string>();
    uptr->size(); // Android Studio incorrectly reports error for unique ptr: "Applying '->' operator to '...' instead of a pointer"

    auto sptr = std::make_shared<std::string>();
    sptr->size(); // Correct for shared_ptr
}

int main(int argc, char **argv) {
    exampleMapIterable();
    exampleUniquePtr();
    return 0;
}

by adding this to my CMakeLists.txt:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++14")

above the cmake_minimum_required line.

I verified the fix on version

Android Studio 3.0
Build #AI-171.4408382, built on October 20, 2017
JRE: 1.8.0_152-release-915-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

as well as the latest canary.

The issue isn't compilation (the file is intended to compile fine), but rather Android Studio reports the errors for unique_ptr and map iterables when there shouldn't be. Even when including the <memory> lib which is given by the fact that shared_ptr shows no error yet unique_ptr incorrectly reports the error

Sorry, my language was imprecise.  I am able to remove the errors with the CMake and C++ changes that I noted in #4.

I can still see the errors in:

Android Studio 3.0.1
Build #AI-171.4443003, built on November 9, 2017
JRE: 1.8.0_152-release-915-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

as well as in:

Android Studio 3.1 Canary 9
Build #AI-173.4559767, built on January 23, 2018
JRE: 1.8.0_152-release-1024-b02 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

As mentioned, they are not compilation errors, as the app can run fine, but rather inspections:
 - Array issues - 'map<string, char>' is not a valid range type
 - Pointer type required - Applying '->' operator to 'std::unique_ptr<std::string>' instead of a pointer

They only seem to appear when using static stl runtime:
        externalNativeBuild {
            cmake {
                arguments "-DANDROID_STL=c++_static"
            }
        }

František, can you include all the C++ source code and CMakeLists.txt that caused these inspections to show up?  I was able to remove the inspections using the setting set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++14") in my CMake configuration and checking that all the headers were properly included.

Here is a sample project: https://github.com/ghus-raba/UniquePtrTest

I was able to use --std=c++11 if I don't use std::make_unique. It behaves the same with --std=c++14.

The warnings (errors?) go away if I comment out [arguments "-DANDROID_STL=c++_static"] in build.gradle and sync. They appear again if I uncomment it and sync.

Thanks for the help.  This does appear to happen with both c++_static and c++_shared.

This suggests that we're incorrectly parsing the <map> and/or <memory> includes for libc++, but not those for libgnustl.  For the unique_ptr issue, we probably just didn't find (or failed to parse correctly) the operator-> definition in the libc++ headers.  I don't know what it looks for to determine ranged-for suitability (maybe begin() and end()?).

I think that's correct.

I can click through to the definition of operator-> for unique_ptr gnu-libstdc++ but not libc++.

This is unfortunate since libc++ is going to become the singular STL option in the future.  We should get syntax highlighting properly working for it.

For the std::unique_ptr issue, it looks like the following code is a minimal reproducing example:

#include <type_traits>

template <class>
struct create_void_type { typedef void type; };

template <class _Tp, class = void>
struct has_pointer_type : std::false_type {};

template <class _Tp>
struct has_pointer_type<_Tp,
        typename create_void_type<typename _Tp::pointer>::type> : std::true_type {};

template<typename T, typename D, bool = has_pointer_type<D>::value>
struct Quux {
    typedef D type;
};

template<typename T, typename D>
struct Quux<T, D, false> {
    typedef T type;
};

template <typename T, typename D>
struct Baz {
    typedef typename Quux<T, D>::type type;
    type get(type t) {
       return t;
    }
};

struct A {};

int y() {
    Baz<int, A> b;
    int i = b.get(1);  // Android studio incorrectly reports error no matter which STL is used.
    return i;
}

I would guess a similar idiom is used in libc++'s implementation of std::map, causing Android Studio to report an error for that.

This is superficially similar to bugs like https://youtrack.jetbrains.com/issue/CPP-11411 and https://youtrack.jetbrains.com/issue/CPP-5883 that already exist in Jetbrains's bug system. SFINAE (http://en.cppreference.com/w/cpp/language/sfinae) is not quite implemented correctly in the IDE.  I verified that the snippet I shared in #16 also has an incorrect error marked in CLion.

This bug is affecting a project I'm working on as well.

So is the temporary workaround of commenting out [arguments "-DANDROID_STL=c++_static"] in build.gradle reasonable until the bug is fixed? What are the ramifications of doing this? My project seems to still build and run fine when I comment this out, so I'm wondering what I'm actually doing / how effective of a solution this is.

Also, I'm curious as to what the various severity and priority levels mean, since I noticed this bug got moved from P1 to P2.

I'm a little confused that commenting that out works.  What NDK version are you on?  If it's r17+, I'd expect that libc++ would be the default STL and you wouldn't see a highlighting change.

If it's an older NDK, then you're implicitly changing the STL you build with.  It's fine in the short term if it's producing working/correct builds, but it's not a good long term solution* since the other STLs are less correct and are going to get cleaned out of the NDK in the next few releases.  

* The good long term solution is for us to fix this issue.

nm on the confusion: jetlag gave me an off-by-one error in the current ndk studio version.  So yeah, this should work in the short term, but medium term you'll have to explicitly specify one of the semi-deprecated STLs and long term we just need to fix it (or force people to pin to old NDKs, which would be really bad)

Just to add, I also see an error on this code:

std::unique_ptr<std::string> createUniqueString() {
    return std::unique_ptr<std::string>(new std::string);
}

There is "Template arguments issues -> Value expected instead of type" pointing to <std::string>. Again, it checks ok on other STLs.

Although these errors don't cause the code to fail compilation, there are a few areas where they hinder our development:
    - When commiting, they are found in code analysis and force us to commit file even with errors. This can make other errors go unnoticed and be commited as well.
    - We are unable to navigate to method definition via ctrl+click.
    - Methods called on unique_ptr are not included when "Find Usages" is invoked. This makes us go back to ctrl+shift+F and manually searching for correct usages, which is not ideal.

A more relevant youtrack issue to watch is https://youtrack.jetbrains.com/issue/CPP-12185

Those that are following this bug: please try 3.2 Canary 7 -- it contains a fix from Jetbrains that we have cherrypicked.