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.

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

[2.10.x] assorted fixes for vampire macros #2902

Closed
wants to merge 2 commits into from

Conversation

@xeno-by
Copy link
Member

@xeno-by xeno-by commented Aug 31, 2013

As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.

However, since such macros are on the intersection of a number of language
features, as usual, there are bugs. This pull requests fixes a couple of them.

As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.

However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.

This commit fixes an unwanted interaction of macros defined in structural
types with the scala.language.reflectiveCalls guard. Since macro calls
aren't going to be carried to runtime, there's no need to warn about them.
@xeno-by

This comment has been minimized.

Copy link
Member Author

@xeno-by xeno-by commented on d9a18fb Aug 31, 2013

How come this commit fails mima with:

     [echo] Checking backward binary compatibility for scala-reflect (against 2.10.0)
     [mima] Found 1 binary incompatibiities (40 were filtered out)
     [mima] ======================================================
     [mima]  * method compactifyName(java.lang.String)java.lang.String in trait
     [mima]    scala.reflect.internal.StdNames does not have a correspondent in old version

@retronym @adriaanm @gkossakowski Does this ring a bell? Looks like something spurious...

This comment has been minimized.

Copy link
Member

@gkossakowski gkossakowski replied Sep 4, 2013

@xeno-by: it doesn't ring any bell for me...

This comment has been minimized.

Copy link
Member

@retronym retronym replied Sep 4, 2013

PLS REBUILD/pr-scala@d9a18fb

@retronym
Copy link
Member

@retronym retronym commented Sep 11, 2013

From the mailing list, @odersky said:

After thinking some more about it, I want to come back to the suggestion of Stefan: Macros can never override but they can overload normal methods. We get the required subtyping between structural types without any further rules that way.

Also, unlike what we thought at the meeting, we need not change the overloading rules to make this work well. In the primary use case of having a foreach macro on Range, that macro already takes precedence over any inherited method in overloading resolution, because it is defined in a subclass of IndexedSeq#foreach.

Finally, with that change, we can drop the rule that prevents a macro from overriding an abstract method, since no overriding is possible in the first place. Everything gets simpler across the board.

Conclusion: I agree with the aims of the pull request, but we should pick a different mechanism to achieve them.

@xeno-by Does this PR need refurbishment in light of Martin's comments?

@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Sep 11, 2013

@retronym That's what I wanted to discuss yesterday, but we all were so carried away by hygiene :)

I suggest we wait until the next week's reflection meeting.

@retronym
Copy link
Member

@retronym retronym commented Sep 11, 2013

@xeno-by I'll be at the office again today, so we can discuss if you're @ EPFL.

@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Sep 11, 2013

Don't know whether I'll be at EPFL today - Strange Loop is nearing.

@retronym
Copy link
Member

@retronym retronym commented Sep 11, 2013

No probs. I'll close this PR for now.

@retronym retronym closed this Sep 11, 2013
@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Sep 24, 2013

Just discussed this at the reflection meeting and decided to reopen as is.

@xeno-by xeno-by reopened this Sep 24, 2013
@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Sep 24, 2013

review @retronym

@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Sep 24, 2013

Btw would be great to have this in M6.

@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Oct 1, 2013

@adriaanm The build is green, but github is still yellow. Is this spurious?

@adriaanm
Copy link
Member

@adriaanm adriaanm commented Oct 1, 2013

This is how we encode that an earlier commit failed whereas the last one was fine. Github only looks at the last commit, so it needs to be marked "failed" if any earlier commit failed.

@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Oct 1, 2013

PLS REBUILD ALL

@scala-jenkins
Copy link

@scala-jenkins scala-jenkins commented Oct 1, 2013

(kitty-note-to-self: ignore 25469076)
🐱 Roger! Rebuilding pr-scala for d9a18fb, b779b216. 🚨

As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.

However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.

Before this commit, subtyping checks between structural types didn't
distinguish regular methods structural types (zombies, as per Travis'
classification) and macros (vampires, again as per the same bestiary).

There's one detail though. Since implicit conversions are looked up using
structural types, that look like: "? { def foo: ? }", where question marks
stand for WildcardType, we need to allow such structural types to match
situations when the target member is a macro.

Unlike the original subtyping rule, this one is not a soundness hole,
because: 1) the way the compiler uses such types is guaranteed to be sound,
because they aren't assigned to any term and are discarded right away
after implicit search, 2) users can't actually write such types, so they
can't exploit the situations that lead to unsoundness.
@xeno-by
Copy link
Member Author

@xeno-by xeno-by commented Oct 4, 2013

Okay since our discussion is going on at #2993, I'm closing this one for the time being.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.