Skip to content
Commits on Aug 5, 2013
  1. paradise 2.0.0-SNAPSHOT

    scalamacros committed Aug 5, 2013
Commits on Jun 4, 2013
  1. @xeno-by
  2. @xeno-by

    fundep materialization beta 1

    This fix provides implicit macros with an ability to affect type inference
    in a more or less sane manner. That's crucial for materialization of
    multi-parametric type class instances (e.g. Iso's from shapeless).
    Details of the technique can be found in comments. Also see the discussion
    at scala#2499.
    xeno-by committed Apr 30, 2013
  3. @xeno-by

    macro annotations alpha 1

    unfortunately the original idea of hijacking enterSym didn't work
    (see the comments in Namers.enterSym for more information), so I had
    to resort to a very ugly hack, since I do need macro annots right away
    xeno-by committed Mar 4, 2013
Commits on Jun 3, 2013
  1. @martende @xeno-by

    jit macro compiler alpha 1

    Allows using macro implementations in the same compilation unit that
    defines them if you enable -Xmacro-jit. Very-very experimental.
    martende committed with xeno-by Feb 27, 2013
  2. @xeno-by
  3. @xeno-by

    SI-6859 type macros no longer crash sbt

    By mimicking alias types, macro types no longer trip a sanity check
    in sbt 0.12 and 0.13:
    This workaround makes me sad but it's the only option to make type macros
    immediately useful. Principled fix pending.
    xeno-by committed Dec 25, 2012
  4. @xeno-by
  5. @xeno-by


    xeno-by committed Dec 25, 2012
  6. @xeno-by

    Merge pull request #2577 from scalamacros/pullrequest/paradise

    Backport from paradise/macros
    xeno-by committed Jun 3, 2013
Commits on Jun 2, 2013
  1. @xeno-by
  2. @xeno-by
Commits on May 31, 2013
  1. @JamesIry

    Merge pull request #2613 from retronym/ticket/6309

    SI-6309 Test case for early-init / private[this] crasher.
    JamesIry committed May 31, 2013
  2. @JamesIry

    Merge pull request #2618 from paulp/pr/final-in-package-object

    Finalized math.E and math.Pi.
    JamesIry committed May 31, 2013
  3. @paulp

    Finalized math.E and math.Pi.

    Without this treatment these constants will not be inlined
    or folded, bloating bytecode and inhibiting optimization.
    Marking them @inline doesn't have any additional effect, but
    I did it to futurize them in light of SI-7542.
    paulp committed May 31, 2013
  4. @paulp

    Merge pull request #2592 from paulp/issue/7088

    SI-7088 Array crasher in erasure.
    paulp committed May 31, 2013
  5. @paulp

    Merge pull request #2614 from paulp/pr/revert-fs

    Revert "SI-6039 Harden against irrelevant filesystem details"
    paulp committed May 31, 2013
  6. @paulp

    Revert "SI-6039 Harden against irrelevant filesystem details"

    This reverts commit b0758f5.
    This commit sent startup time through the roof, at least
    in some circumstances (it is presumably related to one's
    current working directory.)
    paulp committed May 31, 2013
  7. @retronym

    SI-6309 Test case for early-init / private[this] crasher.

    This has worked since 98daf03, "Overhauled local/getter/setter name logic.".
    retronym committed May 30, 2013
Commits on May 29, 2013
  1. @JamesIry

    Merge pull request #2424 from rjolly/si-7399

    SI-7399 : Take scala.concurrent.context.maxThreads into account
    JamesIry committed May 29, 2013
  2. @rjolly

    SI-7399 : Take scala.concurrent.context.maxThreads into account

    This change fixes the bug whereby specifiying maxThread as a property
    has no effect. A small refactoring is applied in the process.
    rjolly committed Apr 21, 2013
Commits on May 28, 2013
  1. @JamesIry

    Merge pull request #2563 from soc/SI-7474

    SI-7474 Parallel collections: End the exception handling madness
    JamesIry committed May 28, 2013
  2. @JamesIry

    Merge pull request #2579 from vigdorchik/list_map

    SI-7502 removing non-existent element from ListMap leaves it unchaged.
    JamesIry committed May 28, 2013
  3. @soc

    SI-7474 Parallel collections: End the exception handling madness

    "What's wrong with an API which non-deterministically returns either
    type A or type B(Set(A, ...))?"
    This is pretty much what the exception handling behavior of the
    parallel collections does: If exceptions of type A occur, either an
    exception of type A or an exception of type B, wrapping multiple
    exceptions of A's, is returned.
    This behavior is incredibly broken and so unintuitive, that even
    people writing tests don't handle it correctly, as seen in test
    Concerning “non-deterministic”:
    How many exceptions are observed before the operation is aborted
    depends on the machine, the available cores and hyper-threading,
    the operating system, the threadpool implementation and
    configuration, the size of the collection and the runtime itself.
    In fact, files/run/t5375.scala can be made to fail reproducible
    on both jdk7u and Avian, if we run on a single-core machine
    like in a virtual machine.
    With this change, we just pass the "first" exception which occurs.
    This is
    - consistent with the behaviour of sequential collections,
    - doesn't require users to know more about parallel collections
    than they already do ("elements might be processed out of order"),
    - in line with what Java 8 does.
    “Why don't we wrap everything in CompositeThrowables?”
    Even consistently returning CompositeThrowable doesn't make much
    sense (because we have fail-fast behaviour and don't wait until
    all tasks have finished or have thrown an exception).
    Therefore, there is no useful semantic in having a
    CompositeThrowable which returns "some" exceptions.
    I have done extensive research into C#'s approach (which is very
    similar to what Scala did until now, but even more messy) and
    the key observation from asking multiple C# developers is that
    not a single one had understood how PLINQ handled exceptions or
    could describe the semantics of it.
    As a consequence, either
    a) gather and return all exceptions in a CompositeThrowable or
    b) just return one, unwrapped,
    instead of non-deterministically wrapping a non-deterministic
    number of exceptions into a completely unrelated wrapper type.
    Considering that changing the parallel collection semantics in
    such a profound way as described in a) is out of question, b)
    is chosen.
    As soon as Scala targets Java > 7 Throwable#addSurpressed can be
    used to add further exceptions to the one which gets returned.
    This would allow passing more information to the caller without
    compromising the simplicity of the API.
    soc committed May 19, 2013
  4. @paulp

    Merge pull request #2593 from paulp/pr/no-numeric-widen

    Make all numeric coercions explicit.
    paulp committed May 28, 2013
  5. @xeno-by
  6. @xeno-by
  7. @xeno-by

    refactors macro runtimes

    Following typedMacroBody, macroRuntime along with its friends has also
    been moved out into a separate component.
    xeno-by committed Feb 27, 2013
  8. @xeno-by

    refactors macro compilation

    Upgrades the way that macro defs are compiled by factoring out most of
    the logic in typedMacroBody and related errors in ContextErrors into an
    standalone cake. This leads to tighter cohesion and better code reuse
    as the cake is isolated from the rest of the compiler and is much easier
    to evolve than just a method body.
    Increased convenience of coding macro compilation allowed me to further
    clarify the implementation of the macro engine (e.g. take a look at
    Validators.scala) and to easily implement additional features, namely:
    1) Parameters and return type of macro implementations can now be plain
    c.Tree's instead of previously mandatory c.Expr's. This makes macros more
    lightweight as there are a lot of situations when one doesn't need to
    splice macro params (the only motivation to use exprs over trees). Also
    as we're on the verge of having quasiquotes in trunk, there soon will be
    no reason to use exprs at all, since quasiquotes can splice everything.
    2) Macro implementations can now be defined in bundles, standalone cakes
    built around a macro context:
    This further reduces boilerplate by simplifying implementations complex
    macros due to the fact that macro programmers no longer need to play
    path-dependent games to use helpers.
    xeno-by committed Jan 19, 2013
  9. @xeno-by

    refactors importers

    Introduces better names, factors out recreation of symbols, trees, types
    and completes into separate methods, so that they can be overridden in
    specialized importers.
    The original motivation for this refactoring was to support JIT
    compilation of macros, but I think that most of the introduced
    improvements to code quality will be useful in trunk.
    xeno-by committed Feb 27, 2013
  10. @xeno-by

    refactors macro tests

    putting in a nutshell, this patch:
      * condenses some macro-XXX-a/b/c/... bundles
      * renames some tests to prepare for other macro flavors
      * introduces some additional tests
    xeno-by committed Jan 14, 2013
  11. @xeno-by

    macro engine refactoring

    Macro impl bindings now store more information in signatures.
    Previously it was a flattened List[Int] corresponding to flattened paramss,
    now it's List[List[Int]] to preserve the lengths of parameter lists.
    Also now we distinguish between c.Expr parameters and others.
    Previously actual and reference macro signatures were represented as
    tuples of vparamss, rets, and sometimes tparams. Now they are all
    abstracted behind MacroImplSig.
    Finally this patch provides better error messages in cases of
    argsc <-> paramsc and argc <-> paramc mismatches.
    xeno-by committed Jan 14, 2013
Commits on May 27, 2013
  1. @xeno-by

    SI-7461 c.typeCheck(silent = true) now suppresses ambiguous errors

    Otherwise use cases like the one shown in the attached test (trying to
    typecheck something, which leads to an ambiguous overload error) will
    mysteriously fail compilation.
    xeno-by committed May 9, 2013
  2. @xeno-by

    less magic in fast track macros

    Now that we have a mechanism to declare not implemented macros, let's put
    it to good use by reducing the amount of magic applied to fast track.
    xeno-by committed May 5, 2013
  3. @xeno-by
Something went wrong with that request. Please try again.