This reverts commit e035c8adf2d1c7ef6d152c377994df1acc162975.

Reason for revert: Breaks enum value to int conversion

---

enum E { V = 0xFFFF'FFFF };
Q_ENUM(E)

Without patch:
console.log(E.V) -> -1

With patch:
console.log(E.V) -> -1
console.log(E.V) -> 4294967295 (QV4_FORCE_INTERPRETER=1)

Fixes: QTBUG-146583
Change-Id: Idd6c21abeb791d568fd3982b4f1dc570d1020741
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

This allows up to 53bit integers to be accurately represented. That's
better than the previous 32bit, but still not the full 64bit range we
would like. (In fact you can represent even larger numbers if no two set
bits are further than 53 bits apart, but let's ignore that for now.)

Remove the misguided and now-dysfunctional optimization for enums from
the "Qt" namespace in qqmlcustomparser.cpp. Matching the namespace by
name is a bad idea since it's possible to shadow that name and there are
a few enum values in the "Qt" namespace that don't fit into int.

[ChangeLog][QtQml] The QML engine does not forcibly truncate enum values
to 32bit anymore. It instead stores them in the native JavaScript number
type, which is effectively C++ double. That means values up to 53bit can
be accurately represented. You should not expose enums larger than that
to QML. The enums you can define in QML remain unaffected. Those are
still capped to 32bit.

Task-number: QTBUG-145053
Change-Id: Ibcd54e1a6cdd7e3293977c9caaec92c2359ab1a2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

In QQmlVMEMetaObjectEndpoint::tryConnect(), the deep alias code path
reads the intermediate object via QMetaObject::metacall(ReadProperty).
If that intermediate object property hasn't been initialized yet (e.g.
during object construction ordering), the ReadProperty call writes null
into the target pointer. The subsequent connect() call then crashes
trying to use the null target.

Add a null check after the ReadProperty metacall and return early if
the target resolved to null. This avoids the crash and leaves the
endpoint unconnected (tag not set to EndPointIsConnected), so it can
be retried on a subsequent notification.

Pick-to: 6.11 6.8
Fixes: QTBUG-143361
Change-Id: I4d103cdf9d81e933afeb46c4b6a186ee4433cb35
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>

If we expect a QML identifier, and the user gives us a reserved keyword,
we can tell them as much, instead of completely failing parsing with a
hard-to-decipher error message.

For now, we don't attempt to recover from the parser error in the
linter/LSP. We could however most likely continue further semantic
analysis, by treating the reserved word as a normal identifier. That
might however lead to some confusing errors in other contexts, and is
therefore avoided for now.

Pick-to: 6.11
Fixes: QTBUG-144691
Change-Id: I9090ef1e4984e5c1d223b6df58f543bdb31e83c6
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>

Aliases can point to IDs. You can't have bindings on plain IDs.
Therefore, removing a binding from such an alias is a noop.

Pick-to: 6.11 6.10 6.8
Fixes: QTBUG-124476
Change-Id: I6ac49bea025c9c5a72485130831cdbdbe0237ec3
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>

When we reorder aliases topologically, we need to also update the
indexOfDefaultPropertyOrAlias, as that could otherwise point to the
wrong alias.
Amends 2dc11fd23c4607174878af6025b84ba5052650b8, which introduced the
topological alias sort to fix a crash.

Fixes: QTBUG-144701
Pick-to: 6.11 6.10 6.11.0 6.10.3
Change-Id: Icf733ca954ab346be9b94157a179a2c46439692d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

resolveDeepAlias() previously only searched the target object's
bindings and aliases to find the sub-property for a deep alias
like 'alias foo: target.groupProp.innerProp'. This failed when
'groupProp' had no inline binding in the document.

Fall back to looking up the sub-property on the declared type's
property cache (via QQmlMetaType::propertyCacheForType) when no
binding or alias match is found.

Apply the same fix to the CompilationUnit specialization in
qqmltypedata.cpp.

Fixes: QTBUG-130605
Change-Id: I7f4d1c9af951c4059ce216f66d5f01d4c1757536
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>

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>

We can have aliases of local aliases. In order to resolve those, we
need to:

1. Look at aliases in addition to properties when trying to find the
   target.
2. Sort the aliases topoligically so that when we try to resolve an
   alias-to-alias its dependency has been resolved already.

We have to append aliases to the property cache in the same order as
they appear in the compilation unit. There is other code that depends on
this.

Amends commit 75dcbb156b2b1dfe0bb43e3119735f26f848e0f6.
Amends commit 9e1378260a3f3a6eb4cad8d6ae47bc218e6a2b5f.

Pick-to: 6.11 6.10
Fixes: QTBUG-144327
Change-Id: Ia8c0a1b060cd4247af20961d349d86e49dd0c895
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

For quite a while the column number was missing when reporting a top
level error of the QQmlComponent. This patch fixes it.

Task-number: QTBUG-141950
Change-Id: Icc5bcf8b5f78d7a380b4effe20c5e5db646fbdc2
Pick-to: 6.11
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>