Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Xml attribute fixes #87

Merged
merged 2 commits into from
Jan 9, 2012
Merged

Xml attribute fixes #87

merged 2 commits into from
Jan 9, 2012

Conversation

khernyo
Copy link
Contributor

@khernyo khernyo commented Jan 7, 2012

  • Fixed equality and string representation of xml attributes with null value
  • Accept prefixed xml attributes with null value

More details can be found in the commit messages.

@khernyo
Fixed equality and string representation of xml attributes with null …
4787f88 
…value

Prior to this patch <t a={ null: String }/> was not equal to <t/> and
it's string representation was "<t ></t>" instead of "<t></t>"

This includes changing MetaData.normalize() so that it doesn't reverse
the chain. On the downside, the iterate function in MetaData.normalize()
is not tail-recursive now.
@khernyo
Accept prefixed xml attributes with null value
51089b3 
This changes makes PrefixedAttribute work the same way as
UnprefixedAttribute with respect to null values:

<t p:a={ null: String }/> is accepted and results in <t/>
@paulp paulp merged commit 51089b3 into scala:master Jan 9, 2012
folone pushed a commit to folone/scala that referenced this pull request Dec 5, 2014
Merge pull request scala#87 from folone/fix-sip23
f308ab0 
Fix .check files for SIP-23
szeiger pushed a commit to szeiger/scala that referenced this pull request Mar 20, 2018
@julienrf
Merge pull request scala#87 from szeiger/wip/immutable-array
ffb9c51 
Support for immutable arrays
eed3si9n pushed a commit to eed3si9n/scala that referenced this pull request May 14, 2019
@smarter
Include used types in the set of used names
ca9a66d 
When `B2.scala` replaces `B.scala` in the new test
`types-in-used-names-a`, the name hash of `listb` does not change because
the signature of `C.listb` is still `List[B]`, however users of
`C.listb` have to be recompiled since the subtyping relationships of its
type have changed.

This commit does this by extending the definition of "used names" to
also include the names of the types of trees, even if these types
do not appear in the source like `List[B]` in `D.scala` (since `B` has
been invalidated, this will force the recompilation of `D.scala`).

This commit does not fix every issue with used types as illustrated by
the pending test `types-in-used-names-b`, `B.scala` is not recompiled
because it uses the type `T` whose hash has not changed, but `T` is
bounded by `S` and `S` has changed, so it should be recompiled.
This should be fixable by including the type bounds underlying a
`TypeRef` in `symbolsInType`.

The test `as-seen-from-a` that did not work before shows that we may not
have to worry about tracking prefixes in `ExtractAPI` anymore, see the
discussion in scala#87 for more information.
eed3si9n pushed a commit to eed3si9n/scala that referenced this pull request May 14, 2019
@smarter
Simplify value class API handling and fix sbt/sbt#2497
9d9d0a7 
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to scala#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.
hrhino added a commit to hrhino/scala that referenced this pull request Oct 12, 2019
@hrhino
Reuse buffers in pickler
c9e3492 
Each `Pickle` object previously contained an `index` and `entries`,
which are only used to populate the raw pickle bytes. Profiles show
this as a significant source of allocations in some runs, and since
the arrays backing these collections are held until jvm, the memory
is likely to survive for several garbage collections and be tenured
into an older space.

Since the `bytes` array is the actual result of the pickling, this
commit moves the other large (mutable!) collections to the pickler
phase factory itself, and arranges that they be cleared before use
and replaced at the end of each pickler phase (so as not to retain
the memory for longer than needed). As a sanity check, each pickle
has a field `active` which is used to assert that accesses to both
mutable fields is safe -- it's set to false when they're cleared.

The new override of `clear` in `AnyRefMap` is safe, since scala
itself currently generates calls to `AnyRefMap.clear` when asked to:

```
[nix-shell:/code/scala/sandbox]$ scala -version
Scala code runner version 2.12.9 -- Copyright 2002-2019, LAMP/EPFL and Lightbend, Inc.

[nix-shell:/code/scala/sandbox]$ cat Test.scala
object Test extends App {
  val map = new collection.mutable.AnyRefMap[String, Int]()
  map("a") = 0
  map.clear()
}

[nix-shell:/code/scala/sandbox]$ scalac Test.scala -d .

[nix-shell:/code/scala/sandbox]$ javap -c Test\$.class | grep '\.clear'
      28: invokevirtual scala#87                 // Method scala/collection/mutable/AnyRefMap.clear:()V
```
hrhino added a commit to hrhino/scala that referenced this pull request Oct 13, 2019
@hrhino
Reuse buffers in pickler
dd45991 
Each `Pickle` object previously contained an `index` and `entries`,
which are only used to populate the raw pickle bytes. Profiles show
this as a significant source of allocations in some runs, and since
the arrays backing these collections are held until jvm, the memory
is likely to survive for several garbage collections and be tenured
into an older space.

Since the `bytes` array is the actual result of the pickling, this
commit moves the other large (mutable!) collections to the pickler
phase factory itself, and arranges that they be cleared before use
and replaced at the end of each pickler phase (so as not to retain
the memory for longer than needed). As a sanity check, each pickle
has a field `active` which is used to assert that accesses to both
mutable fields is safe -- it's set to false when they're cleared.

The new override of `clear` in `AnyRefMap` is safe, since scala
itself currently generates calls to `AnyRefMap.clear` when asked to:

```
[nix-shell:/code/scala/sandbox]$ scala -version
Scala code runner version 2.12.9 -- Copyright 2002-2019, LAMP/EPFL and Lightbend, Inc.

[nix-shell:/code/scala/sandbox]$ cat Test.scala
object Test extends App {
  val map = new collection.mutable.AnyRefMap[String, Int]()
  map("a") = 0
  map.clear()
}

[nix-shell:/code/scala/sandbox]$ scalac Test.scala -d .

[nix-shell:/code/scala/sandbox]$ javap -c Test\$.class | grep '\.clear'
      28: invokevirtual scala#87                 // Method scala/collection/mutable/AnyRefMap.clear:()V
```
hrhino added a commit to hrhino/scala that referenced this pull request Oct 15, 2019
@hrhino
Reuse buffers in pickler
cf477a0 
Each `Pickle` object previously contained an `index` and `entries`,
which are only used to populate the raw pickle bytes. Profiles show
this as a significant source of allocations in some runs, and since
the arrays backing these collections are held until jvm, the memory
is likely to survive for several garbage collections and be tenured
into an older space.

Since the `bytes` array is the actual result of the pickling, this
commit moves the other large (mutable!) collections to the pickler
phase factory itself, and arranges that they be cleared before use
and replaced at the end of each pickler phase (so as not to retain
the memory for longer than needed). As a sanity check, each pickle
has a field `active` which is used to assert that accesses to both
mutable fields is safe -- it's set to false when they're cleared.

The new override of `clear` in `AnyRefMap` is safe, since scala
itself currently generates calls to `AnyRefMap.clear` when asked to:

```
[nix-shell:/code/scala/sandbox]$ scala -version
Scala code runner version 2.12.9 -- Copyright 2002-2019, LAMP/EPFL and Lightbend, Inc.

[nix-shell:/code/scala/sandbox]$ cat Test.scala
object Test extends App {
  val map = new collection.mutable.AnyRefMap[String, Int]()
  map("a") = 0
  map.clear()
}

[nix-shell:/code/scala/sandbox]$ scalac Test.scala -d .

[nix-shell:/code/scala/sandbox]$ javap -c Test\$.class | grep '\.clear'
      28: invokevirtual scala#87                 // Method scala/collection/mutable/AnyRefMap.clear:()V
```
lrytz pushed a commit to lrytz/scala that referenced this pull request Nov 5, 2019
@smarter
Include used types in the set of used names
6966322 
When `B2.scala` replaces `B.scala` in the new test
`types-in-used-names-a`, the name hash of `listb` does not change because
the signature of `C.listb` is still `List[B]`, however users of
`C.listb` have to be recompiled since the subtyping relationships of its
type have changed.

This commit does this by extending the definition of "used names" to
also include the names of the types of trees, even if these types
do not appear in the source like `List[B]` in `D.scala` (since `B` has
been invalidated, this will force the recompilation of `D.scala`).

This commit does not fix every issue with used types as illustrated by
the pending test `types-in-used-names-b`, `B.scala` is not recompiled
because it uses the type `T` whose hash has not changed, but `T` is
bounded by `S` and `S` has changed, so it should be recompiled.
This should be fixable by including the type bounds underlying a
`TypeRef` in `symbolsInType`.

The test `as-seen-from-a` that did not work before shows that we may not
have to worry about tracking prefixes in `ExtractAPI` anymore, see the
discussion in scala#87 for more information.

Rewritten from sbt/zinc@350afa7
lrytz pushed a commit to lrytz/scala that referenced this pull request Nov 5, 2019
@smarter
Simplify value class API handling and fix sbt/sbt#2497
f1d3170 
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to scala#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

Rewritten from sbt/zinc@1e7e99e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@khernyo @paulp