| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first step in disentangling api#Symbol.isPackage, which is
supposed to return false for package classes, and internal#Symbol.isPackage,
which has traditionally being used as a synonym for hasPackageFlag and
hence returned true for package classes (unlike isModule which is false
for module classes).
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 2fa2db7840 I fixed a bug where applicable implicit conversions
would not be found for numeric types if one introduced any aliasing
or singleton types, for the usual reasons involving the absence of
uniform type normalization. See pos/t7228 for examples - that test
case has 20 errors in 2.10.3 but compiles in master.
An unintended side effect was making implicit search less oblivious.
It turns out that in so doing I had created ambiguity where there was
none before. Not because it was any more ambiguous, but because the
compiler now had the wits to notice the ambiguity at an earlier time.
The fix for this is not intuitive. The way the internal logic is,
we need to keep the wool over implicit search's eyes, which leads
to those unrecognized types being passed to adapt, where they are
recognized and weak subtyping suffices to be more specific. It is
sufficient for SI-7228 that weak subtyping be done correctly - the
other change, which is reverted here, was exposing the type arguments
of Function1 when a view exists as a subtype of Function1.
It is also possible this could be remedied by calling weak_<:<
somewhere which is presently <:<, but I don't know where and it
has a far greater chance of affecting something else than does
this, which is a straight reversion of a post-2.10.3 change.
|
|/
|
|
|
| |
Continuing in the direction set by the parent commit, this commit
rephrases some more usages of `local` in names and comments in typer.
|
|
|
|
|
| |
Shadowing is rarer than implausbility; this seems to be
the most efficient way to order these filters.
|
|\
| |
| | |
Prohibit views targeting AnyVal
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Library changes in Scala 2.10 mean that we are left with the
unfortunate situation of admitting:
scala> "": AnyVal
res0: AnyVal =
We already have explicit checks in place to prevent views
targeting `AnyRef`. This commit balances this out by prohibiting
`AnyVal`, as well.
The enclosed test shows that this case is now prevented. If multiple
implicits views are applicable, the ambiguity error is still raised;
these check comes right at the end. Maybe that ought to be changed,
but I don't think it matters too much.
I've also disabled this prohibition under -Xsource:2.10.
|
|\ \
| |/
|/| |
SI-8151 Remove -Yself-in-annots and associated implementation
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This experimental option typechecked arguments of annotations
with an injected value in scope named `self`:
@Foo(self.foo < 1)
This has been slated for removal [1] for some time.
This commit removes it in one fell swoop, without any attempt
at source compatibility with code that constructs or pattern
matches on AnnotatedType.
[1] https://groups.google.com/d/msg/scala-internals/VdZ5UJwQFGI/C6tZ493Yxx4J
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
|\
| |
| | |
correctly fails implicit search for invalid implicit macros
|
| |
| |
| |
| |
| |
| |
| | |
There was a rare corner case when implicit search wouldn’t discard
an invalid implicit macro (e.g. the one with mismatching macro impl or
the one with macro impl defined in the same compilation run) during
typechecking the corresponding candidate in typedImplicit1. This is now fixed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While debugging pos/t7983.scala, I noticed that:
complexity(scala.type): 1
complexity(Int): 2
The intent of the code is that top level classes should have
a complexity of one. This commit restores that for cases when
we see the prefix type as a ThisType, rather than a SingleType.
I can't construct a test case in which this small difference
is observable in the divergence checks.
|
| |
| |
| |
| |
| |
| | |
And use List#sum, rather than a fold.
No functional change.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As seen in Slick. Regressed in 039b1cb1a5b8.
In that commit, a call to `normalize` was replaced with `dealiasWiden`
as part of a broad sweeping change. However, while the latter does
less than the former with regards to eta expansion ofhigher kinded
type refs (the motivation of that commit), it also does more when it
comes to singleton types: they are widened to the underlying type.
This was widening away `SingleType(<<package a.b>>, <<package c>>)`
before the special case assiging that type component a complexity of
zero could kick in.
In the test case, extracted from Slick, this meant that the
divergence check would consider that the second type below to
outrank the first in the complexity measure, and abort the implicit
search.
Shape[?, ? (Coffees, Coffees), ?]
Shape[DivergenceTest.this.Flat, ?, Coffees, ?]
After this change, the number of packages enclosing `DivergenceTest`
no longer has a bearing on the complexity score of the type.
Here's how the race was run before hand:
complexity(<noprefix>): 0
complexity(<root>): 1
complexity(foo.type): 2
complexity(foo.bar.type): 3
complexity(foo.bar.baz.type): 4
complexity(DivergenceTest.this.type): 5
complexity(<noprefix>): 0
complexity(<root>): 1
complexity(foo.type): 2
complexity(foo.bar.type): 3
complexity(foo.bar.baz.type): 4
complexity(DivergenceTest.this.type): 5
complexity(DivergenceTest.this.Flat): 6
complexity(<noprefix>): 0
complexity(<root>): 1
complexity(scala.type): 2
complexity(Int): 3
complexity(?): 1
complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 16
complexity(<noprefix>): 0
complexity(<root>): 1
complexity(foo.type): 2
complexity(foo.bar.type): 3
complexity(foo.bar.baz.type): 4
complexity(DivergenceTest.this.type): 5
complexity(?): 1
complexity(<noprefix>): 0
complexity(<root>): 1
complexity(scala.type): 2
complexity(<noprefix>): 0
complexity(Coffees): 1
complexity(<noprefix>): 0
complexity(<root>): 1
complexity(scala.type): 2
complexity(Int): 3
complexity((Coffees, Int)): 7
complexity(?): 1
complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 15
dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): true
And afterwards:
complexity(DivergenceTest.this.type): 1
complexity(DivergenceTest.this.type): 1
complexity(DivergenceTest.this.Flat): 2
complexity(scala.type): 1
complexity(Int): 2
complexity(?): 1
complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 7
complexity(DivergenceTest.this.type): 1
complexity(?): 1
complexity(scala.type): 1
complexity(<noprefix>): 0
complexity(Coffees): 1
complexity(scala.type): 1
complexity(Int): 2
complexity((Coffees, Int)): 5
complexity(?): 1
complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 9
dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): false
Notice that even in the after shot, `scala.Int` has a complexity of 2.
It should be 1; this will be fixed in a separate commit.
|
|
|
|
|
|
|
|
|
| |
When an application of a blackbox macro is used as an implicit candidate,
no expansion is performed until the macro is selected as the result of
the implicit search.
This makes it impossible to dynamically calculate availability of
implicit macros.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are all used to calls to `definitions.PredefModule`, or
`defintions.Predef_???` to grab the symbol of some well known
entity. But you'll notice that some of these are lazy vals,
and others are defs.
Why is this so? In the presentation compiler, a member like
`Predef.???` will be assigned a new symbol after the user
browses into `Predef.scala`.
Mistakenly using vals in definitions leads to subtle
IDE bugs like SI-7678. We are able to trigger these
situations in tests, as noted in the comments of that issue.
Changing the vals to defs, on the other hand, has a performance
penalty. Some schemes to workaround this have shown up:
cache them per-implicit search, or compare method names and owners
rather than symbols on hot paths in the type checker.
This commit introduces a facility to cache these sort of symbols
per-run, and uses it to check for `Predef.conforms` and
and for the class/type tag materializers.
A followup pull request (WIP: https://github.com/retronym/scala/compare/ticket/7678-2)
will expand the use of to address the widespread and unsafe caching
of member symbols that I found while investigating SI-7678.
|
|
|
|
|
|
|
|
| |
An optimization in implicit search.
ImplicitInfo-s themselves are cached (per-run) in Contexts
(for in-scope implicits) and in Implicits (for companion object
implicits.)
|
|
|
|
|
|
| |
These show up often due to the way that searches for
implicit views operate: firstly `A=>B` is sought, and
failing that `(=>A) => B`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit search created a nested Context into which the results of
its typechecking, namely, errors and undetermined type parameters
(roughly: those inferred as Nothing) are stashed.
The code the drives the process was checking for errors, but
discarded those undetermined type parameters.
This commit copies them from the child context to the parent,
which lets `Typer#adapt` to get to:
else if (hasUndetsInMonoMode) { // (9)
assert(!context.inTypeConstructorAllowed, context) //@M
instantiatePossiblyExpectingUnit(tree, mode, pt)
}
Our lost TypeVar has found its way home! The reward for which
is being instantiated, based on another type inference session
adapting the expression's type to the expected type.
|
|
|
|
| |
Avoid creating a throwaway list of parameter types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simple patch makes it possible for implicit views to benefit from
fundep-guided type inference, eliminating a nasty special case in
implicit inference.
Here are the changes that I had to apply to the tests (they exposed
quite a number of interesting questions that I was happy to answer):
1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense,
because the test was just a canary to track previous state of things.
2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala
changed their messages to less informative ones, because inapplicable
implicit views now get disqualified early and therefore don't display
their error messages to the user. This is an unfortunate but necessary
byproduct of this change, and one can argue that the behavior is now
completely consistent with implicit vals (that also don't explain why
this or that implicit val got disqualified, but rather display a generic
implicit value not found message).
3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala.
Immediate culling of apriori inapplicable implicit views messes things up
for Scaladoc, because it's interested in potentially applicable views,
having infrastructure to track various constraints (type bounds, requirements
for implicit parameters, etc) that guide applicability of views and then
present it to the user. Therefore, when scaladoc is detected, implicit search
reverts to the old behavior.
4) We still cannot have Jason's workaround to type constructor inference
mentioned in comments to SI-3346, because it's not really about implicit
parameters of implicit views, but about type inference flowing from the
implicit parameter list to a preceding parameter list in order to affect
inference of an implicit view. This is something that's still too ambitious.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This idea brought to you by retronym.
Also improve implicitNotFound detection at typer;
and avoid checking the standard interpolation
expression for cases like s"some $$x".
Some minor refactorings of implicitNotFound strings.
The intersobralator allows extra spaces, i.e., trims.
|
|
|
|
|
|
|
| |
Since 4d6be05c28, we've been a tad wasteful in implicit searches.
This adds a by-name parameter to the local logging method to
avoid that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's the obvious translation from a raw Int into a value class.
It wasn't that long ago one could find a signature like this:
def merge(tps: List[Type], variance: Int, depth: Int): Type
Do you feel lucky, method caller? Well, do ya?
Anyway, now it is:
def merge(tps: List[Type], variance: Variance, depth: Depth): Type
Forget for a moment the fact that you'd probably rather not pass variance
for depth and depth for variance and look at the type signatures:
(List[Type], Variance, Depth) => Type
(List[Type], Int, Int) => Type
|
|
|
|
|
| |
in various places. This includes actors, compiler (mostly some new
macro parts) continuations, partest, scaladoc, scalap.
|
|
|
|
|
|
| |
I won't even try to explain the error reporting code, because
it would have no basis in reality. However this change appears
to fix the symptom reported.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase eligibility requirements for implicit conversions,
such that T => U is ineligible if
T <: Null <or> AnyRef <: U
This has the salutary effect of allowing us to ditch 16
ridiculous implicits from Predef, since they existed solely
to work around the absence of this restriction.
There was one tiny impact on actual source code (one line
in one file) shown here, necessitated because the literal null
is not eligible to be implicitly converted to A via <:<.
def f[A](implicit ev: Null <:< A): A = null // before
def f[A](implicit ev: Null <:< A): A = ev(null) // after
As impositions go it's on the tame side.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* pr/merge-2.10.2:
SI-7375 ClassTag for value class aliases
SI-7507 Fix lookup of private[this] member in presence of self type.
SI-7532 Fix regression in Java inner classfile reader
SI-7517 Fix higher kinded type inference regression
SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"
A test case for a recent LUB progression.
SI-7421 remove unneeded extra-attachement in maven deploy
SI-7486 Regressions in implicit search.
SI-7509 Avoid crasher as erronous args flow through NamesDefaults
SI-6138 Centralize and refine detection of `getClass` calls
SI-7497 Fix scala.util.Properties.isMac
SI-7473 Bad for expr crashes postfix
Increase build.number to 2.10.3
SI-7391 Always use ForkJoin in Scala actors on ... ... Java 6 and above (except when the porperty actors.enableForkJoin says otherwise)
Reimplementing much of the DefaultPromise methods Optimizations: 1) Avoiding to call 'synchronized' in tryComplete and in tryAwait 2) Implementing blocking by using an optimized latch so no blocking ops for non-blockers 3) Reducing method size of isCompleted to be cheaper to inline 4) 'result' to use Try.get instead of patmat
c.typeCheck(silent = true) now suppresses ambiguous errors
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
src/compiler/scala/reflect/macros/contexts/Typers.scala
src/compiler/scala/reflect/reify/package.scala
src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala
src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/library/scala/concurrent/impl/Promise.scala
src/reflect/scala/reflect/internal/Types.scala
|
| |
| |
| |
| | |
Revert e86832d7e8 and dd33e280e2.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The "For convenience, these are usable as stub implementations"
bit has generated surprisingly few angry letters, but I noticed
today it blows it on raw types. Or, used to blow it.
/** As seen from class Sub, the missing signatures are as follows.
* For convenience, these are usable as stub implementations.
* (First one before this commitw as 'def raw(x$1: M_1)'
*/
def raw(x$1: M_1[_ <: String]): Unit = ???
def raw(x$1: Any): Unit = ???
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have lots of core classes for which we need not go through
the symbol to get the type:
ObjectClass.tpe -> ObjectTpe
AnyClass.tpe -> AnyTpe
I updated everything to use the concise/direct version,
and eliminated a bunch of noise where places were calling
typeConstructor, erasedTypeRef, and other different-seeming methods
only to always wind up with the same type they would have received
from sym.tpe. There's only one Object type, before or after erasure,
with or without type arguments.
Calls to typeConstructor were especially damaging because (see
previous commit) it had a tendency to cache a different type than
the type one would find via other means. The two types would
compare =:=, but possibly not == and definitely not eq. (I still
don't understand what == is expected to do with types.)
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Implicits.scala
src/reflect/scala/reflect/runtime/JavaMirrors.scala
|
| |
| |
| |
| | |
What a touchy beast the compiler is.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
================================================================
Merge commit 'v2.10.1-326-g4f8c306' into merge/v2.10.1-326-g4f8c306-to-master
Conflicts:
src/compiler/scala/tools/nsc/typechecker/SuperAccessors.scala
src/reflect/scala/reflect/runtime/JavaMirrors.scala
================================================================
Merge -s ours 4e64a27 ([nomaster commit range])
================================================================
Merge commit '0ae7e55' into merge/v2.10.1-326-g4f8c306-to-master
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Macros.scala
|
| |
| |
| |
| | |
This is a port of https://github.com/scala/scala/commit/4e64a2731d from 2.10.x.
|
| |
| |
| |
| |
| |
| | |
This is a port of https://github.com/scala/scala/commit/8168f118c9 from 2.10.x,
with an additional change to the `enclosingImplicits` and `openImplicits` APIs,
which encapsulates tuples of `pt` and `tree` into `ImplicitCandidate`.
|
| |\
| | |
| | | |
Hardening against nulls for deserialization.
|
| | |
| | |
| | |
| | |
| | |
| | | |
When one attempts to populate data structures via
deserialization, nulls tend to show up in unlikely or
"impossible" places. Now there are a few fewer.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
| |
| |
| |
| |
| |
| |
| |
| | |
What seemed like a good idea initially (since potentially there were
many different kinds of errors that could be treated specially),
started to complicate the error logic.
So let's just match on the specific instance of an error to
manipulate the buffer.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since we don't throw exceptions for normal errors it was a bit odd
that we don't do that for DivergingImplicit.
As SI-7291 shows, the logic behind catching/throwing exception
was broken for divergence. Instead of patching it, I rewrote
the mechanism so that we now another SearchFailure type related
to diverging expansion, similar to ambiguous implicit scenario.
The logic to prevent diverging expansion from stopping the search
had to be slightly adapted but works as usual.
The upside is that we don't have to catch diverging implicit
for example in the presentation compiler which was again showing
that something was utterly broken with the exception approach.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Use `firstError match {}` rather than `if (c.hasErrors) c.firstError ..`
- Convert implementation comments to doc comments
- Add new doc comments
- Refactor `Context#make` for better readability.
- Note a few TODOs.
- Roughly delineate the internal structure of Contexts with comments.
- Combine `mode` and `state` methods into `contextMode`.
- Move `isNameInScope` closer to its compadres.
- Improving alignment, tightening access.
|
| |
| |
| |
| |
| |
| |
| |
| | |
- merge `Context#{buffer, warningBuffer}` into `Context#reportBuffer`.
- only expose immutable copies of the error and warnings buffers
- Introduce a convenience method, `firstError`.
- replace `condBufferFlush` more specific methods to retain or
clear errors by error kind.
|
| |
| |
| |
| |
| |
| |
| | |
This commit shortens expressions of the form `if (settings.debug.value)` to
`if (settings.debug)` for various settings. Rarely, the setting is supplied
as a method argument. The conversion is not employed in simple definitions
where the Boolean type would have to be specified.
|