Skip to content
This repository has been archived by the owner on Sep 1, 2020. It is now read-only.

Add an @uninferrable annotation #17

Closed
puffnfresh opened this issue Sep 5, 2014 · 7 comments
Closed

Add an @uninferrable annotation #17

puffnfresh opened this issue Sep 5, 2014 · 7 comments
Labels
defunct enhancement
Milestone
Parked

Comments

@puffnfresh
Copy link

I think #14 makes us want to avoid forking scala-library.jar but maybe we can still figure out a way to make this annotation.
@puffnfresh
Copy link
Author

I think this is more flexible and useful than #16.

@Blaisorblade
Copy link

I think this is more flexible and useful than #16.

👍

From #16:

We should be able to add just an annotation without requiring a flag.

But I'd proposing to use it in the std.lib., potentially breaking/revealing bugs in all clients.
Uses only in client software are fine though.

@non non mentioned this issue Sep 5, 2014
Open
@Blaisorblade Blaisorblade mentioned this issue Sep 5, 2014
Closed
@propensive
Copy link

Should it be @NonInferrable or @nonInferrable? I prefer the latter because it's more compatible with the sorts of annotations I'm more familiar with, though I agree there's no consistency.

@non
Copy link

non commented Sep 5, 2014

How about @uninferrable which dodges the whole question?

@propensive
Copy link

Well, there's nothing to stop us using @Uninferrable... but I like your suggestion. I'm changing the ticket.

@propensive
Copy link

Ok, I can't do that. But @puffnfresh can.

@puffnfresh puffnfresh changed the title Add a @NonInferrable annotation Add a @Uninferrable annotation Sep 5, 2014
@puffnfresh puffnfresh changed the title Add a @Uninferrable annotation Add an @Uninferrable annotation Sep 5, 2014
aloiscochard pushed a commit to aloiscochard/scala that referenced this issue Sep 5, 2014
@adriaanm
Merge pull request typelevel#17 from som-snytt/issue/missing-debug
bcdbb90 
SI-8382 Restore partest.debug
@propensive propensive changed the title Add an @Uninferrable annotation Add an @uninferrable annotation Sep 6, 2014
folone pushed a commit that referenced this issue Aug 14, 2015
@retronym
SI-9425 Leave Companion.apply if constructor is less accessible
f5dc96b 
Calls to synthetic case class apply methods are inlined to the
underlying constructor invocation in refchecks.

However, this can lead to accessibility errors if the constructor
is private.

This commit ensures that the constructor is at least as accessible
as the apply method before performing this tranform.

I've manually checked that other the optimization still works in other
cases:

scala> class CaseApply { Some(42)  }
defined class CaseApply

    scala> :javap -c CaseApply
    Compiled from "<console>"
    public class CaseApply {
      public CaseApply();
        Code:
           0: aload_0
           1: invokespecial #9                  // Method java/lang/Object."<init>":()V
           4: new           #11                 // class scala/Some
           7: dup
           8: bipush        42
          10: invokestatic  #17                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
          13: invokespecial #20                 // Method scala/Some."<init>":(Ljava/lang/Object;)V
          16: pop
          17: return
    }
@milessabin
Copy link
Member

To resurrect this issue, please rework it as an issue/PR against Lightbend Scala (ie. scala/scala).

@milessabin milessabin added this to the Parked milestone Aug 12, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
defunct enhancement
Projects
None yet
Milestone
Parked
Development

No branches or pull requests
5 participants
@puffnfresh @milessabin @non @Blaisorblade @propensive