Fix snippets in Other new features and Usage section

Author: pikinier20

docs/docs/reference/other-new-features/control-syntax.md

@@ -8,6 +8,16 @@ Scala 3 has a new "quiet" syntax for control expressions that does not rely on
 enclosing the condition in parentheses, and also allows to drop parentheses or braces
 around the generators of a `for`-expression. Examples:
 ```scala
+//{
+importjava.io.IOException
+typeT
+varx:Int
+varxs:List[Int]
+varys:List[Int]
+varbody:T
+varhandle:T
+deff(x: Int):Int=???
+//}
 if x <0then
 "negative"
 elseif x ==0then

docs/docs/reference/other-new-features/creator-applications.md

@@ -9,24 +9,26 @@ function application, without needing to write `new`.
 
 Scala 3 generalizes this scheme to all concrete classes. Example:
 
-```scala
-classStringBuilder(s: String):
+```scala sc-name:Base.scala
+classMyStringBuilder(s: String):
 defthis() =this("")
+```
 
-StringBuilder("abc") // old: new StringBuilder("abc")
-StringBuilder() // old: new StringBuilder()
+```scala sc-compile-with:Base.scala
+MyStringBuilder("abc") // old: new MyStringBuilder("abc")
+MyStringBuilder() // old: new MyStringBuilder()
 ```
 
 This works since a companion object with two `apply` methods
 is generated together with the class. The object looks like this:
 
-```scala
-objectStringBuilder:
-inlinedefapply(s: String):StringBuilder=newStringBuilder(s)
-inlinedefapply():StringBuilder=newStringBuilder()
+```scala sc-compile-with:Base.scala
+objectMyStringBuilder:
+inlinedefapply(s: String):MyStringBuilder=newMyStringBuilder(s)
+inlinedefapply():MyStringBuilder=newMyStringBuilder()
 ```
 
-The synthetic object `StringBuilder` and its `apply` methods are called _constructor proxies_.
+The synthetic object `MyStringBuilder` and its `apply` methods are called _constructor proxies_.
 Constructor proxies are generated even for Java classes and classes coming from Scala 2.
 The precise rules are as follows:
 

docs/docs/reference/other-new-features/explicit-nulls.md

@@ -22,6 +22,9 @@ val x: String | Null = null // ok
 A nullable type could have null value during runtime; hence, it is not safe to select a member without checking its nullity.
 
 ```scala
+//{
+valx:String|Null
+//}
 x.trim // error: trim is not member of String | Null
 ```
 
@@ -123,7 +126,7 @@ We illustrate the rules with following examples:
 - The first two rules are easy: we nullify reference types but not value types.
 
 ```java
-classC{
+abstractclassC{
 String s;
 int x;
  }
@@ -132,7 +135,7 @@ We illustrate the rules with following examples:
  ==>
 
 ```scala
-classC:
+abstractclassC:
 vals:String|Null
 valx:Int
 ```
@@ -145,30 +148,33 @@ We illustrate the rules with following examples:
 
  ==>
 
-```scala
-classC[T]{deffoo():T|Null }
+```scala sc-name:C.scala
+classC[T]{deffoo():T|Null=null}
 ```
 
  Notice this is rule is sometimes too conservative, as witnessed by
 
-```scala
+```scala sc:fail sc-compile-with:C.scala
 classInScala:
-valc:C[Bool] =???// C as above
-valb:Bool= c.foo() // no longer typechecks, since foo now returns Bool | Null
+valc:C[Boolean] =???// C as above
+valb:Boolean= c.foo() // no longer typechecks, since foo now returns Bool | Null
 ```
 
 - We can reduce the number of redundant nullable types we need to add. Consider
 
 ```java
-classBox<T>{Tget()}
-classBoxFactory<T>{Box<T>makeBox()}
+abstractclassBox<T>{Tget()}
+abstractclassBoxFactory<T>{Box<T>makeBox()}
 ```
 
  ==>
 
-```scala
-classBox[T]{defget():T|Null }
-classBoxFactory[T]{defmakeBox():Box[T] |Null }
+```scala sc-name:Box.scala
+abstractclassBox[T]{defget():T|Null }
+```
+
+```scala sc-compile-with:Box.scala
+abstractclassBoxFactory[T]{defmakeBox():Box[T] |Null }
 ```
 
  Suppose we have a `BoxFactory[String]`. Notice that calling `makeBox()` on it returns a
@@ -184,16 +190,16 @@ We illustrate the rules with following examples:
 - We will append `Null` to the type arguments if the generic class is defined in Scala.
 
 ```java
-classBoxFactory<T>{
+abstractclassBoxFactory<T>{
 Box<T>makeBox(); // Box is Scala-defined
 List<Box<List<T>>>makeCrazyBoxes(); // List is Java-defined
  }
 ```
 
  ==>
 
-```scala
-classBoxFactory[T]:
+```scala sc-compile-with:Box.scala
+abstractclassBoxFactory[T]:
 defmakeBox():Box[T|Null] |Null
 defmakeCrazyBoxes(): java.util.List[Box[java.util.List[T] |Null]] |Null
 ```
@@ -221,10 +227,13 @@ We illustrate the rules with following examples:
  ==>
 
 ```scala
+//{
+defgetNewName():String=???
+//}
 classConstants:
-valNAME:String("name")="name"
-valAGE:Int(0)=0
-valCHAR:Char('a')='a'
+valNAME:String="name"
+valAGE:Int=0
+valCHAR:Char='a'
 
 valNAME_GENERATED:String|Null= getNewName()
 ```
@@ -242,8 +251,8 @@ We illustrate the rules with following examples:
 
  ==>
 
-```scala
-classC:
+```scala sc-compile-with:Box.scala
+abstractclassC:
 valname:String
 defgetNames(prefix: String|Null): java.util.List[String] // we still need to nullify the paramter types
 defgetBoxedName():Box[String|Null] // we don't append `Null` to the outmost level, but we still need to nullify inside
@@ -252,7 +261,7 @@ We illustrate the rules with following examples:
  The annotation must be from the list below to be recognized as `NotNull` by the compiler.
  Check `Definitions.scala` for an updated list.
 
-```scala
+```scala sc:nocompile
 // A list of annotations that are commonly used to indicate
 // that a field/method argument or return type is not null.
 // These annotations are used by the nullification logic in
@@ -283,11 +292,17 @@ Suppose we have Java method `String f(String x)`, we can override this method in
 
 ```scala
 deff(x: String|Null):String|Null
+```
 
+```scala
 deff(x: String):String|Null
+```
 
+```scala
 deff(x: String|Null):String
+```
 
+```scala
 deff(x: String):String
 ```
 
@@ -304,7 +319,7 @@ Example:
 
 ```scala
 vals:String|Null=???
-if s !=nullthen
+if s !=nullthen???
 // s: String
 
 // s: String | Null
@@ -316,9 +331,12 @@ assert(s != null)
 A similar inference can be made for the `else` case if the test is `p == null`
 
 ```scala
+vals:String|Null=???
 if s ==nullthen
+???
 // s: String | Null
 else
+???
 // s: String
 ```
 
@@ -332,13 +350,16 @@ We also support logical operators (`&&`, `||`, and `!`):
 vals:String|Null=???
 vals2:String|Null=???
 if s !=null&& s2 !=nullthen
+???
 // s: String
 // s2: String
 
 if s ==null|| s2 ==nullthen
+???
 // s: String | Null
 // s2: String | Null
 else
+???
 // s: String
 // s2: String
 ```
@@ -351,11 +372,14 @@ We also support type specialization _within_ the condition, taking into account
 vals:String|Null=???
 
 if s !=null&& s.length >0then// s: String in `s.length > 0`
+???
 // s: String
 
 if s ==null|| s.length >0then// s: String in `s.length > 0`
+???
 // s: String | Null
 else
+???
 // s: String
 ```
 
@@ -442,6 +466,7 @@ We don't support:
 vals:String|Null=???
 vals2:String|Null=???
 if s !=null&& s == s2 then
+???
 // s: String inferred
 // s2: String not inferred
 ```

docs/docs/reference/other-new-features/export.md

@@ -6,7 +6,7 @@ movedTo: https://docs.scala-lang.org/scala3/reference/other-new-features/export.
 
 An export clause defines aliases for selected members of an object. Example:
 
-```scala
+```scala sc-name:Model.scala
 classBitMap
 classInkJet
 
@@ -31,22 +31,22 @@ class Copier:
 
 The two `export` clauses define the following _export aliases_ in class `Copier`:
 
-```scala
+```scala sc:nocompile
 finaldefscan():BitMap= scanUnit.scan()
 finaldefprint(bits: BitMap):Unit= printUnit.print(bits)
 finaltypePrinterType= printUnit.PrinterType
 ```
 
 They can be accessed inside `Copier` as well as from outside:
 
-```scala
+```scala sc-compile-with:Model.scala
 valcopier=newCopier
 copier.print(copier.scan())
 ```
 
 An export clause has the same format as an import clause. Its general form is:
 
-```scala
+```scala sc:nocompile
 exportpath .{sel_1, ..., sel_n }
 ```
 
@@ -86,9 +86,9 @@ referring to private values in the qualifier path
 are marked by the compiler as "stable" and their result types are the singleton types of the aliased definitions. This means that they can be used as parts of stable identifier paths, even though they are technically methods. For instance, the following is OK:
 ```scala
 classC{typeT }
-objectO{valc:C=... }
+objectO{valc:C=??? }
 exportO.c
-deff: c.T=...
+deff: c.T=???
 ```
 
 
@@ -98,7 +98,7 @@ def f: c.T = ...
 1. If an export clause contains a wildcard or given selector, it is forbidden for its qualifier path to refer to a package. This is because it is not yet known how to safely track wildcard dependencies to a package for the purposes of incremental compilation.
 
 1. Simple renaming exports like
-```scala
+```scala sc:nocompile
 exportstatusasstat
  ```
  are not supported yet. They would run afoul of the restriction that the
@@ -142,16 +142,19 @@ ImportSelectors ::= NamedSelector [‘,’ ImportSelectors]
 Export clauses raise questions about the order of elaboration during type checking.
 Consider the following example:
 
-```scala
-class B{val c: Int }
+```scala sc-name:Base.scala
+class B{val c: Int = ??? }
 object a{val b = new B }
+```
+
+```scala sc-compile-with:Base.scala
 exporta.*
 exportb.*
 ```
 
 Is the `export b.*` clause legal? If yes, what does it export? Is it equivalent to `export a.b.*`? What about if we swap the last two clauses?
 
-```
+```scala sc:fail sc-compile-with:Base.scala
 exportb.*
 exporta.*
 ```