regression: new resolution failures in 1.74

[Mark-Simulacrum]

I'm grouping these together but we should make sure all of them are fixed / tested before closing this:

• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/CaviesLabs.hamsterswap-program/log.txt
  • Bisected to resolve: mark binding is determined after all macros had been expanded #115269, but didn't appear as a regression in its crater run
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/RatioFinance.ratio-staking/log.txt
  • Bisected to resolve: mark binding is determined after all macros had been expanded #115269, but didn't appear as a regression in its crater run
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/nosana-ci.nosana-jobs/log.txt
  • Bisected to resolve: mark binding is determined after all macros had been expanded #115269, but didn't appear as a regression in its crater run
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/reg/nmap-analyze-1.0.0/log.txt
  • Known regression resolve: mark binding is determined after all macros had been expanded #115269. Deemed acceptable due to bug fix.
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/reg/luminance-gl-0.19.1/log.txt
  • Bisected to Properly consider binder vars in HasTypeFlagsVisitor #115834
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/reg/luminance-webgl-0.6.1/log.txt
  • Bisected to Properly consider binder vars in HasTypeFlagsVisitor #115834

cc #117053 which is a similar-looking problem, maybe duplicate of this

[INFO] [stdout] error[E0425]: cannot find function `create_lookup_table` in module `instruction`
[INFO] [stdout]   --> programs/swap/src/action/create_address_lookup_table.rs:51:26
[INFO] [stdout]    |
[INFO] [stdout] 51 |             instruction::create_lookup_table(
[INFO] [stdout]    |                          ^^^^^^^^^^^^^^^^^^^ not found in `instruction`
[INFO] [stdout]    |
[INFO] [stdout] help: consider importing this function
[INFO] [stdout]    |
[INFO] [stdout] 1  + use solana_address_lookup_table_program::instruction::create_lookup_table;
[INFO] [stdout]    |
[INFO] [stdout] help: if you import `create_lookup_table`, refer to it directly
[INFO] [stdout]    |
[INFO] [stdout] 51 -             instruction::create_lookup_table(
[INFO] [stdout] 51 +             create_lookup_table(

[apiraino]

I bisected to something different (if my bisection is correct): rollup eb76764 and specifically it says "Regression in rust-lang-ci@7e4f5ec" so cc @jhpratt ?

searched nightlies: from nightly-2023-04-30 to nightly-2023-10-23
regressed nightly: nightly-2023-06-29
searched commit range: 5ea6668...5bd28f5
regressed commit: eb76764

bisected with cargo-bisect-rustc v0.6.7

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc 2023-04-30 --regress error -- check 

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[lqd]

@apiraino That rollup landed in 1.72.

[lqd]

As mark suggests there are different sources here. I haven't checked all of them, but the last 3 look like this:

• luminance-gl-0.19.1 bisects to nightly-2023-09-15, rollup Rollup of 4 pull requests #115848, PR Properly consider binder vars in HasTypeFlagsVisitor #115834 cc author @compiler-errors.
• luminance-webgl-0.6.1 is slightly more involved to bisect because it uses target wasm32-unknown-unknown that we don't build on unrolled perf builds, but points towards the same nightly/rollup. The error looks the same as the -gl version so it's probably safe to assume it would point at the same PR Properly consider binder vars in HasTypeFlagsVisitor #115834.
• nmap-analyze-1.0.0 points to resolve: mark binding is determined after all macros had been expanded #115269, but there was a crater run for it: this crate did indeed show up in the results. As a bug fix, the breakage was deemed acceptable and PRs were opened to fix the 3 broken crates. Here's the one fixing nmap-analyze.

[jhpratt]

I haven't had anything land in this release cycle, so a bisection that leads to me must be incorrect.

[compiler-errors]

I'll investigate luminance-{,web}gl tomorrow.

[apiraino]

thanks @lqd (and sorry for the wrong bisection and ping)

[jhpratt]

No worries!

[wesleywiser]

Bisected nosana-ci.nosana-jobs:

searched toolchains b053db2 through b11431e

Regression in 735bb7e

[apiraino]

thanks @wesleywiser. Also tagging @bvanjoi about this beta regression since author of #115269

[lqd]

Also cc reviewer @petrochenkov, if you two could also weigh in on the first 3 regressions, which didn't appear in the crater run for #115269:

• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/CaviesLabs.hamsterswap-program/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/RatioFinance.ratio-staking/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/nosana-ci.nosana-jobs/log.txt

Felix has been doing some digging on the regressions themselves in this zulip thread.

[bvanjoi]

reduced for hamesterswap:

mod b {
  pub mod instruction {
    pub fn b() {}
  }
}

use b::*;

macro_rules! m {
  () => {
    pub mod instruction {
      pub fn a() {}
    }        
  };
}


// the `hamesterswap-program` uses a procedural macro to generate the instruction module.
// I believe its effect is similar to that of declarative macros
m!();


mod mm {
  use crate::*;
  fn f() {
    instruction::b();
  }
}

I think this is the expected behavior.

[bvanjoi]

reduced for ratio-staking:

// rustc code.rs --cfg 'feature="cpi"'
mod common {
  pub mod cpi {
    pub fn a() {} 
  }

  pub mod macros {
    #[macro_export]
    macro_rules! g {
        () => {
          cpi::a()
        }
    }
  }
}

use common::*;

macro_rules! m {
  () => {
    #[cfg(feature = "cpi")]
    pub mod cpi {
      pub fn b() {}
    }
  };
}

m!();

mod instructions {
  mod stake {
    use crate::*;    
    fn f() {
      g!()
    }
  }
}

I also think that this is the anticipated behavior

Moreover, nosana-jobs employs the same logic as this.

[apiraino]

A few fixes landed since a few weeks. Can this issue be closed?

[wesleywiser]

Revisting, of the 6 crater failures found above, two have been fixed leaving the following:

• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/CaviesLabs.hamsterswap-program/log.txt
  • Bisected to resolve: mark binding is determined after all macros had been expanded #115269, but didn't appear as a regression in its crater run
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/RatioFinance.ratio-staking/log.txt
  • Bisected to resolve: mark binding is determined after all macros had been expanded #115269, but didn't appear as a regression in its crater run
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/gh/nosana-ci.nosana-jobs/log.txt
  • Bisected to resolve: mark binding is determined after all macros had been expanded #115269, but didn't appear as a regression in its crater run
• https://crater-reports.s3.amazonaws.com/beta-1.74-4/beta-2023-10-21/reg/nmap-analyze-1.0.0/log.txt
  • Known regression resolve: mark binding is determined after all macros had been expanded #115269. Deemed acceptable due to bug fix.

The first three are all instances of the same underlying issue and the fourth was known to be a bug fix. It sounds like this is anticipated fallout from the change to fix issues in macro expansion and a PR has been submitted the active project in that set. I'm therefore going to close this issue.