Scala Programming Language
  1. Scala Programming Language
  2. SI-6234

Use consumedTypes/producedTypes in TypeFlowAnalysis and ICodeCheckers

    Details

      Description

      The consumedTypes/producedTypes for icode instructions are redundantly defined in 3 separate places:

      • Opcodes.scala (consumedTypes/producedTypes)
      • ICodeCheckers.scala (for checking icode)
      • TypeFlowAnalysis.scala (for computing types on the stack at each
        program point)

      Since the Opcodes types are the only ones visible outside, I suggest
      we use them in ICodeCheckers.scala and TypeFlowAnalysis.scala too. But
      we should make such changes after the release, after chilling out
      by the lake with a glass of good wine for a couple of days.

      A relevant discussion on this can be found at:
      https://groups.google.com/forum/?fromgroups#!topic/scala-internals/qcyTjk8euUI[1-25]

        Activity

        Hide
        Miguel Garcia added a comment -

        TypeFlowAnalysis does not define any consumedTypes or producedTypes for ICode instructions. The closest it does is using one of them, in just one place, as shown next:

                case cm @ CALL_METHOD(_, _) =>
                  stack pop cm.consumed
                  cm.producedTypes foreach (stack push _)
        

        I don't see why TypeFlowAnalysis should be touched at all.

        Show
        Miguel Garcia added a comment - TypeFlowAnalysis does not define any consumedTypes or producedTypes for ICode instructions. The closest it does is using one of them, in just one place, as shown next: case cm @ CALL_METHOD(_, _) => stack pop cm.consumed cm.producedTypes foreach (stack push _) I don't see why TypeFlowAnalysis should be touched at all.
        Hide
        Vlad Ureche added a comment -

        I guess it would make sense to have it do something like:

          stack popAndCheck cm.consumedTypes
          cm.producedTypes foreach (stack push _)
        

        And the same for all instructions. WDTY?

        Show
        Vlad Ureche added a comment - I guess it would make sense to have it do something like: stack popAndCheck cm.consumedTypes cm.producedTypes foreach (stack push _) And the same for all instructions. WDTY?
        Hide
        Miguel Garcia added a comment -

        There's no need to replace current functionality in TypeFlowAnalysis, which is working fine as we all know.

        Instead, further assertions can be added. In the example, before popping from the stack, an assert can be added to cross-check with cm.consumedTypes.

        Show
        Miguel Garcia added a comment - There's no need to replace current functionality in TypeFlowAnalysis, which is working fine as we all know. Instead, further assertions can be added. In the example, before popping from the stack, an assert can be added to cross-check with cm.consumedTypes .
        Hide
        Vlad Ureche added a comment -

        Also related: SI-5819

        Show
        Vlad Ureche added a comment - Also related: SI-5819
        Hide
        Adriaan Moors added a comment -

        Unassigning and rescheduling to M6 as previous deadline was missed.

        Show
        Adriaan Moors added a comment - Unassigning and rescheduling to M6 as previous deadline was missed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Vlad Ureche
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development