tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (working)
[personal profile] tim
Today: a short day, since staying at work till 11 PM, then taking the bus home, resulted in waking up at 12:30 PM and various other silliness. Not feeling like I'm doing that well at being an adult at the moment.

Today, I was planning to work more on dependencies, but issue 3021 caught my eye. The fix was easy, or so it seemed: resolve was treating impl methods like a "normal function" (which may capture variables defined in its enclosing scope) rather than an "opaque function" (which may not). Closures are normal functions, while function items (declared with fn) are considered opaque. Impl methods should be treated the same way as function items. That was a one-line fix, and allowed this test case to pass. I realized the same fix should apply to class methods and trait methods, as well. The problem is that then, a ty param bound by a class (or impl or trait) gets considered an upvar, and then class methods can't refer to it. Which is to say, this code should be accepted:

class cat {
      fn meow() -> T { ... }
(aside from its lack of a constructor or fields, but you get the picture). It should be okay to refer to T in the definition of meow. But my fix was resulting in T getting considered an upvar in the declaration of meow, which resulted in the code getting rejected with a result error.

Inside the compiler, a type parameter is identified by the pair of the unique identifier of the item that binds it (in this case, cat), and its index in the list of type parameters (in this case, 0, since there's only one type parameter). But something weird appears to be going on in resolve, because when resolving the meow method, type parameter T appears to correspond to some def_id that's neither the def_id for cat, nor the def_id for meow.

I'll have to get to that tomorrow, since I'm deciding to truncate today in the interest of getting started at a better time tomorrow and Friday. Also, I received some very prompt feedback on my IonMonkey patch, which pointed out that (among other things) I'd forgotten about some important things like backwards-compatibility. I'm earmarking the week after I get back (I'll be away most of next week) to work on that; I don't want to procrastinate that for another three months.


tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

July 2014

6 78910 1112
131415 16171819
2021 2223242526
2728 293031  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags