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.

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

Add an `@uninferrable` annotation #17

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

Comments

Projects
None yet
5 participants
@puffnfresh

puffnfresh commented Sep 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@puffnfresh

puffnfresh Sep 5, 2014

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

puffnfresh commented Sep 5, 2014

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

@Blaisorblade

This comment has been minimized.

Show comment
Hide comment
@Blaisorblade

Blaisorblade Sep 5, 2014

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.

Blaisorblade commented Sep 5, 2014

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.

@propensive

This comment has been minimized.

Show comment
Hide comment
@propensive

propensive Sep 5, 2014

Member

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.

Member

propensive commented Sep 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@non

non Sep 5, 2014

Member

How about @uninferrable which dodges the whole question?

Member

non commented Sep 5, 2014

How about @uninferrable which dodges the whole question?

@propensive

This comment has been minimized.

Show comment
Hide comment
@propensive

propensive Sep 5, 2014

Member

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

Member

propensive commented Sep 5, 2014

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

@propensive

This comment has been minimized.

Show comment
Hide comment
@propensive

propensive Sep 5, 2014

Member

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

Member

propensive commented Sep 5, 2014

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

@puffnfresh puffnfresh changed the title from Add a @NonInferrable annotation to Add a @Uninferrable annotation Sep 5, 2014

@puffnfresh puffnfresh changed the title from Add a @Uninferrable annotation to Add an @Uninferrable annotation Sep 5, 2014

aloiscochard pushed a commit to aloiscochard/scala that referenced this issue Sep 5, 2014

@propensive propensive changed the title from Add an @Uninferrable annotation to Add an `@uninferrable` annotation Sep 6, 2014

folone pushed a commit that referenced this issue Aug 14, 2015

SI-9425 Leave Companion.apply if constructor is less accessible
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

This comment has been minimized.

Show comment
Hide comment
@milessabin

milessabin Aug 12, 2016

Member

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

Member

milessabin commented Aug 12, 2016

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

@milessabin milessabin added the defunct label Aug 12, 2016

@milessabin milessabin added this to the Parked milestone Aug 12, 2016

@milessabin milessabin closed this Aug 26, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment