1 files changed, 0 insertions, 163 deletions
diff --git a/src/qml/doc/src/qmllanguageref/documents/definetypes.qdoc b/src/qml/doc/src/qmllanguageref/documents/definetypes.qdoc
index dde54e2af6..df609fb3b9 100644
--- a/src/qml/doc/src/qmllanguageref/documents/definetypes.qdoc
+++ b/src/qml/doc/src/qmllanguageref/documents/definetypes.qdoc
@@ -221,167 +221,4 @@ refer to the \l MouseArea child, and if it had an \c id of \c root rather than
 \c squareButton, this would not conflict with the \c id of the same value for
 the root object defined in \c SquareButton.qml as the two would be declared
 within separate scopes.
-
-\section1 Pragmas
-
-You can prepend global instructions to a QML document using the \c pragma
-keyword. The following pragmas are supported:
-
-\section2 Singleton
-
-\c{pragma Singleton} declares the component defined in the QML document as
-singleton. Singletons are created only once per QML engine. In order to use
-a QML-declared singleton you also have to register it with its module. See
-\l{qt_target_qml_sources} for how to do this with CMake.
-
-\section2 ListPropertyAssignBehavior
-
-With this pragma you can define how assignments to list properties shall be
-handled in components defined in the QML document. By default, assigning to a
-list property appends to the list. You can explicitly request this behavior
-using the value \c{Append}. Alternatively, you can request the contents of list
-properties to always be replaced using \c{Replace}, or replaced if the property
-is not the default property using \c{ReplaceIfNotDefault}. For example:
-
-\qml
-pragma ListPropertyAssignBehavior: ReplaceIfNotDefault
-\endqml
-
-The same declaration can also be given for C++-defined types. See
-\l{QML_LIST_PROPERTY_ASSIGN_BEHAVIOR_APPEND},
-\l{QML_LIST_PROPERTY_ASSIGN_BEHAVIOR_REPLACE}, and
-\l{QML_LIST_PROPERTY_ASSIGN_BEHAVIOR_REPLACE_IF_NOT_DEFAULT}
-
-\section2 ComponentBehavior
-
-With this pragma you can restrict components defined in this file to only
-create objects within their original context. This holds for inline
-components as well as Component elements explicitly or implicitly created
-as properties. If a component is bound to its context, you can safely
-use IDs from the rest of the file within the component. Otherwise, the
-engine and the QML tooling cannot know in advance what type, if any, such
-IDs will resolve to at run time.
-
-In order to bind the components to their context specify the \c{Bound}
-argument:
-
-\qml
-pragma ComponentBehavior: Bound
-\endqml
-
-The default is \c{Unbound}. You can also specify it explicitly. In a
-future version of Qt the default will change to \c{Bound}.
-
-Delegate components bound to their context don't receive their own
-private contexts on instantiation. This means that model data can only
-be passed via \l{Required Properties}{required properties} in this case.
-Passing model data via context properties will not work. This concerns
-delegates to e.g. \l{Instantiator}, \l{Repeater}, \l{ListView},
-\l{TableView}, \l{GridView}, \l{TreeView} and in general anything that
-uses \l{DelegateModel} internally.
-
-For example, the following will \e{not} work:
-
-\qml
-pragma ComponentBehavior: Bound
-import QtQuick
-
-ListView {
-    delegate: Rectangle {
-        color: model.myColor
-    }
-}
-\endqml
-
-The \c{delegate} property of \l{ListView} is a component. Therefore, a
-\l{Component} is implicitly created around the \l{Rectangle} here. That
-component is bound to its context. It doesn't receive the context property
-\c{model} provided by \l{ListView}. To make it work, you'd have to write
-it this way:
-
-\qml
-pragma ComponentBehavior: Bound
-import QtQuick
-
-ListView {
-    delegate: Rectangle {
-        required property color myColor
-        color: myColor
-    }
-}
-\endqml
-
-You can nest components in a QML file. The pragma holds for all components in
-the file, no matter how deeply nested.
-
-
-\section2 FunctionSignatureBehavior
-
-With this pragma you can change the way type annotations on functions are
-handled. By default the interpreter and JIT ignore type annotations, but
-the \l{QML Script Compiler} enforces them when compiling to C++.
-
-Specifying \c{Enforce} as value makes sure the type annotations are always
-enforced. The resulting type coercions increase the overhead of calling
-typed JavaScript functions.
-
-Specifying \c{Ignore} as value makes the \l{QML Script Compiler} ignore
-any JavaScript functions when compiling the document to C++. This means less
-code is compiled to C++ ahead of time, and more code has to be interpreted or
-JIT-compiled.
-
-\sa {Type annotations and assertions}
-
-\section2 ValueTypeBehavior
-
-The behavior of \l{QML Value Types} and list types differs slightly
-depending on whether a QML document is compiled to C++ using the
-\l{QML Script Compiler} or interpreted at run time.
-
-With this pragma you can change the way value types and sequences are handled
-when retrieved as locals from properties. By default, the interpreter and JIT
-treat all value types and sequences as references. This means, if you change
-the local value, the original property is also changed. Furthermore, if you
-write the original property explicitly, the local value is also updated.
-
-When compiled to C++ using the \l{QML Script Compiler}, the local value is not
-updated when the property is written, and the property is only updated when
-written directly, without retrieving it as local value before.
-
-For example, the following code prints "1 1" when compiled to C++ and "5 5"
-when interpreted or JIT-compiled:
-
-\qml
-import QtQml
-
-QtObject {
-    id: root
-
-    property rect r: ({x: 1, y: 2, width: 3, height: 4})
-    property list<double> numbers: [1, 2, 3, 4, 5]
-
-    function manipulate() {
-        root.r = {x: 5, y: 6, width: 7, height: 8};
-        root.numbers = [5, 4, 3, 2, 1];
-    }
-
-    Component.onCompleted: {
-        var numbers = root.numbers;
-        var r = root.r;
-        manipulate()
-        console.log(r.x, numbers[0]);
-    }
-}
-\endqml
-
-You may notice that the behavior when interpreted or JIT-compiled can be rather
-confusing.
-
-Specifying \c{Copy} as value to the pragma makes the interpreter and JIT behave
-like the generated C++ code. This is the recommended way to handle the problem.
-Specifying \c{Reference} makes the \l{QML Script Compiler} skip any functions
-that use value types or sequences when generating C++ code. Those functions are
-then left to be interpreted or JIT-compiled with the default behavior of the
-interpreter and JIT.
-
 */