| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This reverts commit eb5c51383a63c5c3420e53ef021607ff5fd20296.
|
| |\
| |
| |
| | |
Include 99f41a1 Merge pull request #5736
|
| | |\
| | |
| | | |
SI-10206 tighten fix for SI-6889
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Implicit search implements a restriction that the target type for an
implicit view should be more specific that AnyRef or AnyVal.
scala> def foo(s: String): AnyVal = s
<console>:12: error: the result type of an implicit conversion must be more specific than AnyVal
def foo(s: String): AnyVal = s
^
Without this, an implicit value classes over `String` would be applied,
which is unlikely to be what was intended.
Implicit views are implemented as an implicit search for a function type
with a structural type as its result. This structural type is created
with:
scala> val schema = analyzer.HasMethodMatching.apply(TermName("clone"), Nil, WildcardType)
schema: $r.intp.global.analyzer.global.Type = ?{def clone(): ?}
The quirk arises when, as above, we're seeking a member with the same name
as a member of AnyRef. AnyRef is seen to be a subtype of the result type:
scala> AnyRefClass.tpe <:< schema
res23: Boolean = true
Which leads to the implicit in the test case being disqualified. The typer
opts to report the error about the inapplicability of the inherited clone
method, so we don't even know why the implicit was discarded.
|
| | | |
| | |
| | |
| | |
| | | |
There are more supertypes of `AnyRef` than you might think:
`?{def clone: ?}` is one example...
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't emit a synthetic `apply` (or `unapply`) when it would
clash with an existing one. This allows e.g., a `private apply`,
along with a `case class` with a `private` constructor.
We have to retract the synthetic method in a pretty roundabout way,
as we need the other methods and the owner to be completed already.
Unless we have to complete the synthetic `apply` while completing
the user-defined one, this should not be a problem. If this does
happen, this implies there's a cycle in computing the user-defined
signature and the synthetic one, which is not allowed.
|
| | | |
|
| |\ \
| | |
| | | |
SCP-009: Improve direct dependency experience
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The following commit message is a squash of several commit messages.
- This is the 1st commit message:
Add position to stub error messages
Stub errors happen when we've started the initialization of a symbol but
key information of this symbol is missing (the information cannot be
found in any entry of the classpath not sources).
When this error happens, we better have a good error message with a
position to the place where the stub error came from. This commit goes
into this direction by adding a `pos` value to `StubSymbol` and filling
it in in all the use sites (especifically `UnPickler`).
This commit also changes some tests that test stub errors-related
issues. Concretely, `t6440` is using special Partest infrastructure and
doens't pretty print the position, while `t5148` which uses the
conventional infrastructure does. Hence the difference in the changes
for both tests.
- This is the commit message #2:
Add partest infrastructure to test stub errors
`StubErrorMessageTest` is the friend I introduce in this commit to help
state stub errors. The strategy to test them is easy and builds upon
previous concepts: we reuse `StoreReporterDirectTest` and add some
methods that will compile the code and simulate a missing classpath
entry by removing the class files from the class directory (the folder
where Scalac compiles to).
This first iteration allow us to programmatically check that stub errors
are emitted under certain conditions.
- This is the commit message #3:
Improve contents of stub error message
This commit does three things:
* Keep track of completing symbol while unpickling
First, it removes the previous `symbolOnCompletion` definition to be
more restrictive/clear and use only positions, since only positions are
used to report the error (the rest of the information comes from the
context of the `UnPickler`).
Second, it adds a new variable called `lazyCompletingSymbol` that is
responsible for keeping a reference to the symbol that produces the stub
error. This symbol will usually (always?) come from the classpath
entries and therefore we don't have its position (that's why we keep
track of `symbolOnCompletion` as well). This is the one that we have to
explicitly use in the stub error message, the culprit so to speak.
Aside from these two changes, this commit modifies the existing tests
that are affected by the change in the error message, which is more
precise now, and adds new tests for stub errors that happen in complex
inner cases and in return type of `MethodType`.
* Check that order of initialization is correct
With the changes introduced previously to keep track of position of
symbols coming from source files, we may ask ourselves: is this going to
work always? What happens if two symbols the initialization of two
symbols is intermingled and the stub error message gets the wrong
position?
This commit adds a test case and modifications to the test
infrastructure to double check empirically that this does not happen.
Usually, this interaction in symbol initialization won't happen because
the `UnPickler` will lazily load all the buckets necessary for a symbol
to be truly initialized, with the pertinent addresses from which this
information has to be deserialized. This ensures that this operation is
atomic and no other symbol initialization can happen in the meantime.
Even though the previous paragraph is the feeling I got from reading the
sources, this commit creates a test to double-check it. My attempt to be
better safe than sorry.
* Improve contents of the stub error message
This commit modifies the format of the previous stub error message by
being more precise in its formulation. It follows the structured format:
```
s"""|Symbol '${name.nameKind} ${owner.fullName}.$name' is missing from the classpath.
|This symbol is required by '${lazyCompletingSymbol.kindString} ${lazyCompletingSymbol.fullName}'.
```
This format has the advantage that is more readable and explicit on
what's happening. First, we report what is missing. Then, why it was
required. Hopefully, people working on direct dependencies will find the
new message friendlier.
Having a good test suite to check the previously added code is
important. This commit checks that stub errors happen in presence of
well-known and widely used Scala features. These include:
* Higher kinded types.
* Type definitions.
* Inheritance and subclasses.
* Typeclasses and implicits.
- This is the commit message #4:
Use `lastTreeToTyper` to get better positions
The previous strategy to get the last user-defined position for knowing
what was the root cause (the trigger) of stub errors relied on
instrumenting `def info`.
This instrumentation, while easy to implement, is inefficient since we
register the positions for symbols that are already completed.
However, we cannot do it only for uncompleted symbols (!hasCompleteInfo)
because the positions won't be correct anymore -- definitions using stub
symbols (val b = new B) are for the compiler completed, but their use
throws stub errors. This means that if we initialize symbols between a
definition and its use, we'll use their positions instead of the
position of `b`.
To work around this we use `lastTreeToTyper`. We assume that stub errors
will be thrown by Typer at soonest.
The benefit of this approach is better error messages. The positions
used in them are now as concrete as possible since they point to the
exact tree that **uses** a symbol, instead of the one that **defines**
it. Have a look at `StubErrorComplexInnerClass` for an example.
This commit removes the previous infrastructure and replaces it by the
new one. It also removes the fields positions from the subclasses of
`StubSymbol`s.
- This is the commit message #5:
Keep track of completing symbols
Make sure that cycles don't happen by keeping track of all the
symbols that are being completed by `completeInternal`. Stub errors only
need the last completing symbols, but the whole stack of symbols may
be useful to reporting other error like cyclic initialization issues.
I've added this per Jason's suggestion. I've implemented with a list
because `remove` in an array buffer is linear. Array was not an option
because I would need to resize it myself. I think that even though list
is not as efficient memory-wise, it probably doesn't matter since the
stack will usually be small.
- This is the commit message #6:
Remove `isPackage` from `newStubSymbol`
Remove `isPackage` since in 2.12.x its value is not used.
|
| |\ \ \
| | | |
| | | | |
SI-10231 Skip outer parameter when classfile parsing java param names
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Nested java classes have a synthetic outer parameter, which the classfile parser
skips for the constructor symbol. When assigning parameter names from the
MethodParameters classfile attribute, we also need to skip the first name in this
case.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8417 Check adapts of each param section
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, adaptations like auto-tupling were checked
only on the last param section of an application.
This commit runs the sanity check always.
|
| | |/ /
|/| |
| | |
| | | |
thank you tools/rm-orphan-checkfiles script
|
| |\ \ \
| | | |
| | | | |
Don't use `equals` for comparing java.lang.Double/Float
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes https://github.com/scala/scala-dev/issues/329
The `equals` method for java.lang.Double/Float behaves differently than comparing
the `doubleValue`s / `floatValues` for `-0.0`/`0.0`/`NaN`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Follow-up to fb061f22d4c35df626d9651e017820a11f8fe56e
which allowed the type param only.
Reported:
```
scala> object Test {
| def a[R](implicit s: List[R]):Int = 0
| def a_=[R](v: Int)(implicit s: List[R]) = ()
| }
```
|
| |\ \ \ \
| | | | |
| | | | | |
Avoid compiler crash with missing transitive dependencies
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In this test case, the backend forces the specialization
info transform of `Sub` during computation of its
inner class metadata. This in turn runs the info transforms
of the `Base`. This leads to the uncurry info tranform
transforming a signature that has a type alias as a
method parameter type. Subsequent substution of the new
method symbol into the result type, which includes a
stub symbol for an absent class, tripped an assertion:
```
requirement failed: package b
java.lang.IllegalArgumentException: requirement failed: package b
at scala.Predef$.require(Predef.scala:277)
at scala.reflect.internal.Types$ModuleTypeRef.<init>(Types.scala:1879)
at scala.reflect.internal.Types$PackageTypeRef.<init>(Types.scala:1897)
at scala.reflect.internal.Types$TypeRef$.apply(Types.scala:2401)
at scala.reflect.internal.Types.typeRef(Types.scala:3553)
at scala.reflect.internal.Types.typeRef$(Types.scala:3536)
at scala.reflect.internal.SymbolTable.typeRef(SymbolTable.scala:16)
at scala.reflect.internal.Symbols$TypeSymbol.newTypeRef(Symbols.scala:3026)
at scala.reflect.internal.Symbols$TypeSymbol.updateTypeCache(Symbols.scala:3079)
at scala.reflect.internal.Symbols$TypeSymbol.maybeUpdateTypeCache(Symbols.scala:3065)
at scala.reflect.internal.Symbols$TypeSymbol.tpe_$times(Symbols.scala:3043)
at scala.reflect.internal.Symbols$Symbol.typeOfThis(Symbols.scala:2020)
at scala.reflect.internal.Types$ThisType.underlying(Types.scala:1184)
at scala.reflect.internal.Types$SimpleTypeProxy.boundSyms(Types.scala:150)
at scala.reflect.internal.Types$SimpleTypeProxy.boundSyms$(Types.scala:150)
at scala.reflect.internal.Types$SingletonType.boundSyms(Types.scala:1088)
at scala.reflect.internal.tpe.TypeMaps$SubstMap.apply(TypeMaps.scala:726)
at scala.reflect.internal.tpe.TypeMaps$SubstSymMap.apply(TypeMaps.scala:789)
at scala.reflect.internal.tpe.TypeMaps$TypeMap.mapOver(TypeMaps.scala:102)
at scala.reflect.internal.tpe.TypeMaps$SubstSymMap.apply(TypeMaps.scala:783)
at scala.reflect.internal.tpe.TypeMaps$TypeMap.mapOver(TypeMaps.scala:102)
at scala.reflect.internal.tpe.TypeMaps$SubstSymMap.apply(TypeMaps.scala:783)
at scala.reflect.internal.Types$Type.substSym(Types.scala:727)
at scala.reflect.internal.tpe.TypeMaps$TypeMap.mapOver(TypeMaps.scala:123)
at scala.reflect.internal.transform.UnCurry$$anon$1.apply(UnCurry.scala:53)
at scala.reflect.internal.transform.UnCurry.transformInfo(UnCurry.scala:154)
```
This commit address the direct failure above by setting coherent flags on
the stub package class symbol (it also needs the MODULE flag).
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Improved error messages for identically named, differently prefixed types
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Gaze deeper for errors before committing to conversion
of assignment to update. The error buried in the transformed
tree escapes notice of retypechecking and leaks to backend.
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Fix erasure of the qualifier of ##
|
| | |/ / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-10194: Fix abstract type resolution for overloaded HOFs
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Types in the applicable overload alternatives need to be seen from
the respective owners of the individual alternative, not from the
target’s owner (which can be a subtype of the types that define the
methods).
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-10190 Elide string to empty instead of null
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Avoid NPE when eliding string-valued functions.
For example, `log(s"$cheap$expensive")` needn't print null.
This is a natural and inexpensive way to elide strings.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9881 Fix ImportHandler's reporting of importedNames and importedSymbols
|
| | | |_|/ / / /
| |/| | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-10133 Require escaped single quote char lit
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Instead of indenting source code to make messages
align on output, let the reporter add indentation,
only if the source is the console (and not a pastie
or a loaded file).
Previously, syntax errors were not indented.
```
$ skala
Welcome to Scala 2.12.2-20170108-010722-939abf1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_111).
Type in expressions for evaluation. Or try :help.
scala> 'abc'
<console>:1: error: unclosed character literal (or use " for string literal "abc")
'abc'
^
scala> :quit
$ scala
Welcome to Scala 2.12.1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_111).
Type in expressions for evaluation. Or try :help.
scala> 'abc'
<console>:1: error: unclosed character literal
'abc'
^
```
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Folks from other languages might mistakenly enclose
a string in single quotes. Since this presents as
a symbol literal followed by the unpaired single
quote, we can add a syntax reminder.
Also polish the wording for bad string
interpolation.
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The spec specifically requires `'\''` and not `'''`.
The error consumes all consecutive single quotes.
|
| |\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | | |
SI-10026 Fix endless cycle in runtime reflection
|
| | | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
56f23af introduced a call to `baseTypeSeq` of `scala.collection.mutable.ArrayOps.ofRef[?T]{}`
in `findMember`. This exposed a latent bug in the synchronized wrapper of `BaseTypeSeq`,
demonstrated below with an older version of Scala:
```
Welcome to Scala 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_112).
Type in expressions for evaluation. Or try :help.
scala> val symtab = reflect.runtime.universe.asInstanceOf[scala.reflect.internal.SymbolTable]
symtab: scala.reflect.internal.SymbolTable = scala.reflect.runtime.JavaUniverse@458544e0
scala> import symtab._
import symtab._
scala> val ArrayOps_ofRef_Class = symtab.symbolOf[scala.collection.mutable.ArrayOps.ofRef[AnyRef]]
ArrayOps_ofRef_Class: symtab.TypeSymbol = class ofRef
scala> appliedType(symbolOf[Set[Any]], symbolOf[Set[Any]].typeParams.map(TypeVar(_)))
res2: symtab.Type = Set[?A]
scala> .narrow
res3: symtab.Type = <none>.<refinement>.type
scala> .baseTypeSeq
java.lang.StackOverflowError
at scala.reflect.runtime.Gil$class.gilSynchronized(Gil.scala:21)
at scala.reflect.runtime.JavaUniverse.gilSynchronized(JavaUniverse.scala:16)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$class.map(SynchronizedOps.scala:27)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anon$2.map(SynchronizedOps.scala:34)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$class.lateMap(SynchronizedOps.scala:34)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anon$2.lateMap(SynchronizedOps.scala:34)
at scala.reflect.internal.BaseTypeSeqs$MappedBaseTypeSeq.map(BaseTypeSeqs.scala:235)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anon$2.scala$reflect$runtime$SynchronizedOps$SynchronizedBaseTypeSeq$$super$map(SynchronizedOps.scala:34)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anonfun$map$1.apply(SynchronizedOps.scala:27)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anonfun$map$1.apply(SynchronizedOps.scala:27)
at scala.reflect.runtime.Gil$class.gilSynchronized(Gil.scala:19)
at scala.reflect.runtime.JavaUniverse.gilSynchronized(JavaUniverse.scala:16)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$class.map(SynchronizedOps.scala:27)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anon$2.map(SynchronizedOps.scala:34)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$class.lateMap(SynchronizedOps.scala:34)
at scala.reflect.runtime.SynchronizedOps$SynchronizedBaseTypeSeq$$anon$2.lateMap(SynchronizedOps.scala:34)
at scala.reflect.internal.BaseTypeSeqs$MappedBaseTypeSeq.map(BaseTypeSeqs.scala:235)
```
The infinite cycle involves:
```
class MappedBaseTypeSeq(orig: BaseTypeSeq, f: Type => Type) extends BaseTypeSeq(orig.parents map f, orig.elems) {
...
override def map(g: Type => Type) = lateMap(g)
override def lateMap(g: Type => Type) = orig.lateMap(x => g(f(x)))
}
trait SynchronizedBaseTypeSeq extends BaseTypeSeq {
...
override def map(f: Type => Type): BaseTypeSeq = gilSynchronized { super.map(f) }
override def lateMap(f: Type => Type): BaseTypeSeq =
// only need to synchronize BaseTypeSeqs if they contain refined types
if (map(f).toList.exists(_.isInstanceOf[RefinedType])) new MappedBaseTypeSeq(this, f) with SynchronizedBaseTypeSeq
else new MappedBaseTypeSeq(this, f)
}
```
This commit creates a new factory method for `MappedBaseTypeSeq`-s to break the cycle.
As an independent change, I have also removed the attempt to conditionally synchronize them,
as the condition was eagerly applying the map function (and throwing away the result!).
I've appeased MiMa with new whitelist entries, but I'm confident that this is deep enough
in the bowels of our runtime reflection implementation that there is no way that user code
will be calling these methods directly.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This case can be triggered as illustrated in the test.
|
| |/ / / / /
| | | | |
| | | | |
| | | | | |
The test for non-zero must recognize `-0e+00f` and variants.
|
| |\ \ \ \ \
| | |_|/ /
| |/| | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-10148 Follow Java for float literals
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | | |
Use `Float.parseFloat` instead of converting from Double.
Error when a value rounds to zero.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-4700 The thrilling continuation to the infix type printing saga.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add ability to disable this via the @showAsInfix annotation.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
```
scala> import scala.annotation.infix
import scala.annotation.infix
scala> @infix class &&[T, U]
defined class $amp$amp
scala> def foo: Int && Boolean = ???
foo: Int && Boolean
```
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9636 More precise error pos on apply inference
|
