more fixes in Markdown files

docs/docs/internals/syntax.md

@@ -405,7 +405,7 @@ GivenDef          ::=  [GivenSig] (AnnotType [‘=’ Expr] | StructuralInstance
 GivenSig          ::=  [id] [DefTypeParamClause] {UsingParamClause} ‘:’         -- one of `id`, `DefParamClause`, `UsingParamClause` must be present
 StructuralInstance ::=  ConstrApp {‘with’ ConstrApp} ‘with’ TemplateBody
 Extension         ::=  ‘extension’ [DefTypeParamClause] ‘(’ DefParam ‘)’
-                       {UsingParamClause}] ExtMethods
+                       {UsingParamClause} ExtMethods
 ExtMethods        ::=  ExtMethod | [nl] <<< ExtMethod {semi ExtMethod} >>>
 ExtMethod         ::=  {Annotation [nl]} {Modifier} ‘def’ DefDef
 Template          ::=  InheritClauses [TemplateBody]

docs/docs/reference/changed-features/eta-expansion-spec.md

@@ -24,7 +24,7 @@ For methods with one or more parameters like in the example above, this restrict
 
 ## Automatic eta-expansion and partial application
 In the following example `m` can be partially applied to the first two parameters.
-Assignining `m` to `f1` will automatically eta-expand.
+Assigning `m` to `f1` will automatically eta-expand.
 
 ```scala
 def m(x: Boolean, y: String)(z: Int): List[Int]

docs/docs/reference/contextual/extension-methods.md

@@ -290,10 +290,16 @@ TemplateStat      ::=  ... | Extension
 TopStat           ::=  ... | Extension
 Extension         ::=  ‘extension’ [DefTypeParamClause] ‘(’ DefParam ‘)’
                        {UsingParamClause} ExtMethods
-ExtMethods        ::=  ExtMethod | [nl] ‘{’ ExtMethod {semi ExtMethod ‘}’
+ExtMethods        ::=  ExtMethod | [nl] <<< ExtMethod {semi ExtMethod} >>>
 ExtMethod         ::=  {Annotation [nl]} {Modifier} ‘def’ DefDef
 ```
 
+In the above the notation `<<< ts >>>` in the production rule `ExtMethods` is defined as follows :
+
+```
+<<< ts >>>        ::=  ‘{’ ts ‘}’ | indent ts outdent
+```
+
 `extension` is a soft keyword. It is recognized as a keyword only if it appears
 at the start of a statement and is followed by `[` or `(`. In all other cases
 it is treated as an identifier.

docs/docs/reference/dropped-features/do-while.md

@@ -36,7 +36,5 @@ do print(".")
 
 ### Why Drop The Construct?
 
- - `do-while` is used relatively rarely and it can expressed faithfully using just      `while`. So there seems to be little point in having it as a separate syntax          construct.
- - Under the [new syntax rules](../other-new-features/control-syntax.md) `do` is used
-   as a statement continuation, which would clash with its meaning as a statement
-   introduction.
+ - `do-while` is used relatively rarely and it can be expressed faithfully using just `while`. So there seems to be little point in having it as a separate syntax construct.
+ - Under the [new syntax rules](../other-new-features/control-syntax.md) `do` is used as a statement continuation, which would clash with its meaning as a statement introduction.

docs/docs/reference/dropped-features/package-objects.md

@@ -33,13 +33,14 @@ The compiler generates synthetic objects that wrap top-level definitions falling
 
 If a source file `src.scala` contains such top-level definitions, they will be put in a synthetic object named `src$package`. The wrapping is transparent, however. The definitions in `src` can still be accessed as members of the enclosing package.
 
-**Note 1:** This means that the name of a source file containing wrapped top-level definitions is relevant for binary compatibility. If the name changes, so does the name of the generated object and its class.
+**Note:** This means that
+1. The name of a source file containing wrapped top-level definitions is relevant for binary compatibility. If the name changes, so does the name of the generated object and its class.
 
-**Note 2:** A top-level main method `def main(args: Array[String]): Unit = ...` is wrapped as any other method. If it appears
+2. A top-level main method `def main(args: Array[String]): Unit = ...` is wrapped as any other method. If it appears
 in a source file `src.scala`, it could be invoked from the command line using a command like `scala src$package`. Since the
 "program name" is mangled it is recommended to always put `main` methods in explicitly named objects.
 
-**Note 3:** The notion of `private` is independent of whether a definition is wrapped or not. A `private` top-level definition is always visible from everywhere in the enclosing package.
+3. The notion of `private` is independent of whether a definition is wrapped or not. A `private` top-level definition is always visible from everywhere in the enclosing package.
 
-**Note 4:** If several top-level definitions are overloaded variants with the same name,
+4. If several top-level definitions are overloaded variants with the same name,
 they must all come from the same source file.

docs/docs/reference/dropped-features/procedure-syntax.md

@@ -14,5 +14,5 @@ def f(): Unit = { ... }
 ```
 Scala 3 accepts the old syntax under the `-source:3.0-migration` option.
 If the `-migration` option is set, it can even rewrite old syntax to new.
-The [ScalaFix](https://scalacenter.github.io/scalafix/) tool also
+The [Scalafix](https://scalacenter.github.io/scalafix/) tool also
 can rewrite procedure syntax to make it Scala 3 compatible.

docs/docs/reference/dropped-features/weak-conformance-spec.md

@@ -8,14 +8,16 @@ To simplify the underlying type theory, Scala 3 drops the notion of
 altogether. Instead, it provides more flexibility when
 assigning a type to a constant expression. The new rule is:
 
- - If a list of expressions `Es` appears as one of
+ - *If* a list of expressions `Es` appears as one of
 
      - the elements of a vararg parameter, or
      - the alternatives of an if-then-else or match expression, or
      - the body and catch results of a try expression,
 
-   and all expressions have primitive numeric types, but they do not
-   all have the same type, then the following is attempted:
+- *and* all expressions have primitive numeric types, but they do not
+   all have the same type,
+
+- *then* the following is attempted:
 
      - the expressions `Es` are partitioned into `Int` constants on the
        one hand, and all other expressions on the other hand,
@@ -27,12 +29,15 @@ assigning a type to a constant expression. The new rule is:
        unchanged regardless),
      - otherwise, the expressions `Es` are used unchanged.
 
-    A loss of precision occurs for an `Int -> Float` conversion of a constant
-    `c` if `c.toFloat.toInt != c`. For an `Int -> Byte` conversion it occurs
-    if `c.toByte.toInt != c`. For an `Int -> Short` conversion, it occurs
-    if `c.toShort.toInt != c`.
+    A loss of precision occurs for
+    - an `Int -> Float` conversion of a constant
+    `c` if `c.toFloat.toInt != c`
+    - an `Int -> Byte` conversion of a constant
+    `c` if `c.toByte.toInt != c`,
+    - an `Int -> Short` conversion of a constant
+    `c` if `c.toShort.toInt != c`.
 
-## Examples
+### Examples
 
 ```scala
 inline val b = 33

docs/docs/reference/syntax.md

@@ -395,7 +395,7 @@ GivenDef          ::=  [GivenSig] (AnnotType [‘=’ Expr] | StructuralInstance
 GivenSig          ::=  [id] [DefTypeParamClause] {UsingParamClause} ‘:’         -- one of `id`, `DefParamClause`, `UsingParamClause` must be present
 StructuralInstance ::=  ConstrApp {‘with’ ConstrApp} ‘with’ TemplateBody
 Extension         ::=  ‘extension’ [DefTypeParamClause] ‘(’ DefParam ‘)’
-                       {UsingParamClause}] ExtMethods
+                       {UsingParamClause} ExtMethods
 ExtMethods        ::=  ExtMethod | [nl] <<< ExtMethod {semi ExtMethod} >>>
 ExtMethod         ::=  {Annotation [nl]} {Modifier} ‘def’ DefDef
 Template          ::=  InheritClauses [TemplateBody]