[ty] Use "cannot" consistently over "can not" (#21255)

crates/ty_python_semantic/src/place.rs

@@ -733,7 +733,7 @@ pub(crate) fn place_by_id<'db>(
     };
 
     // If a symbol is undeclared, but qualified with `typing.Final`, we use the right-hand side
-    // inferred type, without unioning with `Unknown`, because it can not be modified.
+    // inferred type, without unioning with `Unknown`, because it cannot be modified.
     if let Some(qualifiers) = declared.is_bare_final() {
         let bindings = all_considered_bindings();
         return place_from_bindings_impl(db, bindings, requires_explicit_reexport)

crates/ty_python_semantic/src/semantic_index/reachability_constraints.rs

@@ -13,7 +13,7 @@
 //! of `test`. When evaluating a constraint, there are three possible outcomes: always true, always
 //! false, or ambiguous. For a simple constraint like this, always-true and always-false correspond
 //! to the case in which we can infer that the type of `test` is `Literal[True]` or `Literal[False]`.
-//! In any other case, like if the type of `test` is `bool` or `Unknown`, we can not statically
+//! In any other case, like if the type of `test` is `bool` or `Unknown`, we cannot statically
 //! determine whether `test` is truthy or falsy, so the outcome would be "ambiguous".
 //!
 //!
@@ -29,7 +29,7 @@
 //! Here, we would accumulate a reachability constraint of `test1 AND test2`. We can statically
 //! determine that this position is *always* reachable only if both `test1` and `test2` are
 //! always true. On the other hand, we can statically determine that this position is *never*
-//! reachable if *either* `test1` or `test2` is always false. In any other case, we can not
+//! reachable if *either* `test1` or `test2` is always false. In any other case, we cannot
 //! determine whether this position is reachable or not, so the outcome is "ambiguous". This
 //! corresponds to a ternary *AND* operation in [Kleene] logic:
 //!
@@ -60,7 +60,7 @@
 //! The third branch ends in a terminal statement [^1]. When we merge control flow, we need to consider
 //! the reachability through either the first or the second branch. The current position is only
 //! *definitely* unreachable if both `test1` and `test2` are always false. It is definitely
-//! reachable if *either* `test1` or `test2` is always true. In any other case, we can not statically
+//! reachable if *either* `test1` or `test2` is always true. In any other case, we cannot statically
 //! determine whether it is reachable or not. This operation corresponds to a ternary *OR* operation:
 //!
 //! ```text
@@ -91,7 +91,7 @@
 //! ## Explicit ambiguity
 //!
 //! In some cases, we explicitly record an “ambiguous” constraint. We do this when branching on
-//! something that we can not (or intentionally do not want to) analyze statically. `for` loops are
+//! something that we cannot (or intentionally do not want to) analyze statically. `for` loops are
 //! one example:
 //! ```py
 //! def _():

crates/ty_python_semantic/src/subscript.rs

@@ -27,7 +27,7 @@ fn from_negative_i32(index: i32) -> usize {
     static_assertions::const_assert!(usize::BITS >= 32);
 
     index.checked_neg().map(from_nonnegative_i32).unwrap_or({
-        // 'checked_neg' only fails for i32::MIN. We can not
+        // 'checked_neg' only fails for i32::MIN. We cannot
         // represent -i32::MIN as a i32, but we can represent
         // it as a usize, since usize is at least 32 bits.
         from_nonnegative_i32(i32::MAX) + 1

crates/ty_python_semantic/src/types.rs

@@ -297,7 +297,7 @@ impl AttributeKind {
 /// When invoked on a class object, the fallback type (a class attribute) can shadow a
 /// non-data descriptor of the meta-type (the class's metaclass). However, this is not
 /// true for instances. When invoked on an instance, the fallback type (an attribute on
-/// the instance) can not completely shadow a non-data descriptor of the meta-type (the
+/// the instance) cannot completely shadow a non-data descriptor of the meta-type (the
 /// class), because we do not currently attempt to statically infer if an instance
 /// attribute is definitely defined (i.e. to check whether a particular method has been
 /// called).
@@ -4412,7 +4412,7 @@ impl<'db> Type<'db> {
                 };
 
                 if result.is_class_var() && self.is_typed_dict() {
-                    // `ClassVar`s on `TypedDictFallback` can not be accessed on inhabitants of `SomeTypedDict`.
+                    // `ClassVar`s on `TypedDictFallback` cannot be accessed on inhabitants of `SomeTypedDict`.
                     // They can only be accessed on `SomeTypedDict` directly.
                     return Place::Undefined.into();
                 }
@@ -12050,7 +12050,7 @@ pub(crate) mod tests {
         assert!(todo1.is_assignable_to(&db, int));
 
         // We lose information when combining several `Todo` types. This is an
-        // acknowledged limitation of the current implementation. We can not
+        // acknowledged limitation of the current implementation. We cannot
         // easily store the meta information of several `Todo`s in a single
         // variant, as `TodoType` needs to implement `Copy`, meaning it can't
         // contain `Vec`/`Box`/etc., and can't be boxed itself.

crates/ty_python_semantic/src/types/diagnostic.rs

@@ -2000,7 +2000,7 @@ pub(super) fn report_slice_step_size_zero(context: &InferContext, node: AnyNodeR
     let Some(builder) = context.report_lint(&ZERO_STEPSIZE_IN_SLICE, node) else {
         return;
     };
-    builder.into_diagnostic("Slice step size can not be zero");
+    builder.into_diagnostic("Slice step size cannot be zero");
 }
 
 fn report_invalid_assignment_with_message(

crates/ty_python_semantic/src/types/generics.rs

@@ -714,7 +714,7 @@ fn is_subtype_in_invariant_position<'db>(
         // TODO:
         // This should be removed and properly handled in the respective
         // `(Type::TypeVar(_), _) | (_, Type::TypeVar(_))` branch of
-        // `Type::has_relation_to_impl`. Right now, we can not generally
+        // `Type::has_relation_to_impl`. Right now, we cannot generally
         // return `ConstraintSet::from(true)` from that branch, as that
         // leads to union simplification, which means that we lose track
         // of type variables without recording the constraints under which

crates/ty_python_semantic/src/types/infer/builder.rs

@@ -3804,7 +3804,7 @@ impl<'db, 'ast> TypeInferenceBuilder<'db, 'ast> {
 
                                     let msg = if !member_exists {
                                         format!(
-                                            "Can not assign to unresolved attribute `{attribute}` on type `{}`",
+                                            "Cannot assign to unresolved attribute `{attribute}` on type `{}`",
                                             object_ty.display(db)
                                         )
                                     } else if is_setattr_synthesized {
@@ -3840,7 +3840,7 @@ impl<'db, 'ast> TypeInferenceBuilder<'db, 'ast> {
                                 self.context.report_lint(&UNRESOLVED_ATTRIBUTE, target)
                             {
                                 builder.into_diagnostic(format_args!(
-                                    "Can not assign object of type `{}` to attribute \
+                                    "Cannot assign object of type `{}` to attribute \
                                      `{attribute}` on type `{}` with \
                                      custom `__setattr__` method.",
                                     value_ty.display(db),