There's a number of detectors in the QQmlPrivate namespace, each one
meant to detect the presence of a specific QML_ macro (e.g. QML_FOREIGN,
QML_EXTENDED, and so on). The detectors work by detecting the presence
of some enumeration value, function, etc. injected by the expansion of
those macros in a class.

Since the macros may generally expand in a private: section of a class,
the macros also befriend the detector classes; otherwise the detection
would fail due to the detector being unable to access the
enumeration/etc.

This should work in principle, but there's a problem with the specific
implementation: it uses SFINAE on the detector class itself via
(a small variation of) the usual pattern:

  template <typename T, typename Enable = void>
  struct Detector : std::false_type {}; /* primary */

  template <typename T>
  struct Detector<T, std::void_t</* checks */>> : std::true_type {};

The problem here is that the checks are not necessarily carried with
Detector's own access priviliges. In particular it has been observed
that GCC < 12 and MSVC fail the detection; it seems that the SFINAE is
getting evaluated with the privileges of whoever _uses_ the Detector
class, not of the class itself, making the befriending useless.

Therefore, the code employs a further workaround: the macros also
befriend the (only) usage point of the detectors, that is, the
qmlRegisterTypesAndRevisions function.

This approach seems to work, but it makes the detectors crippled /
creates technical debt. Indeed, an upcoming feature (uncreatable
singletons) attempted to use the detectors directly from some other
code, and the detectors (mysteriously) failed on those compilers.

This commit fixes the detectors so that they always work.
To do so, we're moving to "old school" SFINAE, where the detector
becomes

  template <typename T>
  struct Detector {
    template <typename U>
    static auto test(int) -> /* some expression SFINAE yielding true_type */;

    template <typename U>
    static auto test(...) -> false_type;

    static constexpr bool value = decltype(test<U>(0))::value;
  };

The whole point of this approach is to be well within Detector's scope
and therefore establish friendship, making the detection code work
reliably.

The friendship to qmlRegisterTypesAndRevisions can therefore be removed.

I've tried to minimize the refactorings necessary. The "old style"
SFINAE is indeed clumsier, and it shows. I don't quite understand
why the checks are slightly different between each other (instead of
e.g. just checking the presence of a inner type or constant), or why
some QML macros introduce unused declarations (e.g.
qt_qmlMarker_sequence), so I left them alone.

Change-Id: I618e8b7b4ad47dc22f9d61cce6addac00bf29dc6
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

The header is only used to add meta-data to source files.

Pick-to: 6.10 6.9 6.8
Fixes: QTBUG-136199
Change-Id: Ib2a5c55b68613b9d2c3d7bd619841358201b9341
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

Add NO_PRIVATE_MODULE to the creation flags of module that don't have
any private headers. There's no point in creating private modules for
them.

Task-number: QTBUG-132526
Change-Id: I76b820f3348a5066b0aac740d4e0be8ddeadc4dd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>

This makes qmltyperegistrar lexically replace occurrences of the alias
with the original type. It therefore assumes that the types are actually
the same. It cannot check whether this assumption holds, and you can
actually provide "using" declarations for types that are not the same if
you have the respective conversion operators in place.

Obviously this is quite dangerous. Therefore it remains internal for
now.

Task-number: QTBUG-125240
Change-Id: Idb54cb42fd1289cbd9438272ae3e9e01a30869eb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

When using multiple QML type registration macros, one might end up with
duplicated friend declarations. This is fine as far as C++ is concerned,
but triggers gcc's redundant-decls warning.

Given that we require the friend declaration, and would like to keep it
in the macros that actually need them (instead of putting them into the
macros which are used in all types exposed to QML), we opt for
suppressing the warning.

Pick-to: 6.5 6.7
Fixes: QTBUG-124934
Change-Id: I4f43afddfefb6e546ddddbdc01435222398a06be
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>

Use NO_GENERATE_CPP_EXPORTS explicitly for modules that don't need
the autogenerated exports header file.

Task-number: QTBUG-90492
Change-Id: I6b2b9949f4592de399517dc5e8c7bd96dc7120d6
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

This way we can eventually use the metatypes generated by the builtins
to validate other module using qmltyperegistrar, and throw informed
warnings if types are missing.

qmltyperegistrar automatically picks up the metatypes of any library
linked into a target. This means it always picks up the builtins
metatypes now when QtQml is linked in.

We now have to check more closely whether an object binding is actually
a group property. QVariant now has a value type metaobject and does not
pass as "unknown thing" anymore.

We also have to move the QML_FOREIGN macros to QQmlIntegration since we
want QML_FOREIGN to declare the builtins but we don't want to depend on
QtQml.

Task-number: QTBUG-101143
Change-Id: I9f1a2713797291b6624aef0ade599d19e0766907
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>

Even though it makes no sense, we have to allow QML_ANONYMOUS and
QML_UNCREATABLE in the same class since we've documented it. You
cannot trigger the custom message because you'd need a name to attempt
to create an instance of the type. Therefore, the documentation
suggesting this is nonsensical.

In theory you could indeed provide a custom message for namespaces, but
in order to continue supporting this, we would either have to drop the
QmlIsUncreatable mechanism, or we would need a different macro. So,
let's drop this for now. If we really need it, we can introduce a
different macro later.

[ChangeLog][QtQml][Important Behavior Changes] You can no longer
override the "uncreatable" message for QML-exposed namespaces using
QML_UNCREATABLE. This would be incompatible with making the
QML_UNCREATABLE macro safe from unintended inheritance. The latter is
much more important.

Pick-to: 6.5
Fixes: QTBUG-111470
Change-Id: Ib736a2411128d58d939fa2a57d28a0b31c0777e6
Reviewed-by: Robert Griebl <robert.griebl@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

Pick-to: 6.5
Fixes: QTBUG-104899
Change-Id: I237ddb68968b26c1ce41051ab3bd3c66fb1712f1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>

We allow value types to be created
1. by calling Q_INVOKABLE constructors
2. by setting their values from properties of a JS object

Both have to be opted into by setting a class info. If opted into, these
options override the existing methods. When a a type can be created by
setting its properties, that implies you can also initialize it using an
invokable constructor. However, when given a JS object, the properties
method is used.

We keep this internal and undocumented for now. As the last try (the
create(QJSValue) methods and QJSValue ctors) was not that stellar, let's
first wait a bit and see if we're getting it right this time around.

Fixes: QTBUG-106480
Change-Id: I767230924afcba032d501846cc3263dad57b7bf0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>