diff options
author | Stefan Zeiger <szeiger@novocode.com> | 2016-07-26 20:17:54 +0200 |
---|---|---|
committer | Stefan Zeiger <szeiger@novocode.com> | 2016-08-12 13:38:51 +0200 |
commit | 53d55bc821a11a886094008211d43f2ee9b4c638 (patch) | |
tree | bc2ea8f790659cc9c9bb6384512d4fe4fe8d5394 /test/files/neg | |
parent | 4bc9ca51a4b016bdb9c24a7bcb776ae8d5de9436 (diff) | |
download | scala-53d55bc821a11a886094008211d43f2ee9b4c638.tar.gz scala-53d55bc821a11a886094008211d43f2ee9b4c638.tar.bz2 scala-53d55bc821a11a886094008211d43f2ee9b4c638.zip |
SI-8434 Make generic Set operations build the same kind of Set
When building from a `Set` implementation that was statically seen as
a `collection.GenSet` or `collection.Set`, we used to build a default
`Set` implementation determined by `GenSetFactory.setCanBuildFrom`.
This change modifies `setCanBuildFrom` to determine the correct
implementation at runtime by asking the source `Set`’s companion object
for the `Builder`.
Tests are in `NewBuilderTest.mapPreservesCollectionType`, including lots
of disabled tests for which I believe there is no solution under the
current collection library design.
`Map` suffers from the same problem as `Set`. This *can* be fixed in the
same way as for `Set` with some non-trivial changes (see the note in
`NewBuilderTest`), so it is probably best left for Scala 2.13.
Diffstat (limited to 'test/files/neg')
0 files changed, 0 insertions, 0 deletions