[2.10.x] assorted fixes for vampire macros #2902
Conversation
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.
|
From the mailing list, @odersky said:
@xeno-by Does this PR need refurbishment in light of Martin's comments? |
|
@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. |
|
@xeno-by I'll be at the office again today, so we can discuss if you're @ EPFL. |
|
Don't know whether I'll be at EPFL today - Strange Loop is nearing. |
|
No probs. I'll close this PR for now. |
|
Just discussed this at the reflection meeting and decided to reopen as is. |
|
review @retronym |
|
Btw would be great to have this in M6. |
|
@adriaanm The build is green, but github is still yellow. Is this spurious? |
|
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. |
|
PLS REBUILD ALL |
|
(kitty-note-to-self: ignore 25469076) |
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.
|
Okay since our discussion is going on at #2993, I'm closing this one for the time being. |
5 participants
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.