feat: public cells to allow for implementations of custom Layouter

[alexander-camuto]

The Layouter<F> trait is currently public and exposed and as such enables for the implementation of custom layouters.

However implementations of methods such as constraint_instance is nay impossible without access to the Cell struct's inner elements. Consider the following implementation of constrain_instance:

fn constrain_instance(
        &mut self,
        cell: Cell,
        instance: Column<Instance>,
        row: usize,
    ) -> Result<(), Error> {
        let module_idx = self.region_idx[&cell.region_index];

        self.cs.copy(
            cell.column,
            *self.regions[&module_idx][&cell.region_index] + cell.row_offset,
            instance.into(),
            row,
        )
    }

Without access to cell.region_index and cell.row_offset this would be very difficult / impossible to implement. As such this PR makes these regions public:

/// A pointer to a cell within a circuit.
#[derive(Clone, Copy, Debug)]
pub struct Cell {
    /// Identifies the region in which this cell resides.
    pub region_index: RegionIndex,
    /// The relative offset of this cell within its region.
    pub row_offset: usize,
    /// The column of this cell.
    pub column: Column<Any>,
}

Further to allow for complete Layouter implementation we also expose SimpleTableLayouter publicly for reuse.

pub use floor_planner::single_pass::SimpleTableLayouter;

• pros: more flexibility for end consumers of the halo2 api in terms of implementing custom Layouter, RegionLayouter, TableLayouter.

• cons: opening up the cell struct in this manner could create subtle soundness bugs for applications that are playing around with it.

Let me know what you think :)

[han0110]

LGTM, just some nitpicks, I've also tried to implement cutsom layouter and faced the same issue, so I think it makes sense for us to expose the api to allow us do some experiments.

[han0110]

seems to be unnecessary change?

[alexander-camuto]

Was done to resolve some warnings that popped up

[han0110]

The same thing pops up again unfortunately

[alexander-camuto]

@han0110 I've bumped the toolchain to 1.65.0 -- because one of the pulled in packages is no longer compatible with 1.64.0 and triggers the following error in the CI (without an old Cargo.lock):

addr2line v0.21.0 cannot be built because it requires rustc 1.65 or newer, while the currently active rustc version is 1.64.0

The bump to 1.65.0 then triggers new clippy lints in the CI -- which I've also patched to allow for the CI to pass !

[han0110]

LGTM! Thanks for fixing all the clippy stuff.