My project upgraded to 1.1.0, but compilation fails

[mryndzionek]

My project upgraded to 1.1.0, but compilation fails most likely due to cortex-m-rtic-macros not being updated to 1.1.0 in main Cargo.toml. The root cause seems to be this commit missing (MASKS missing in macros/src/codegen/util.rs).

[perlindgren]

You can try deleting the Cargo.lock, clean the project and do a cargo update`.

If this does not help we can have a closer look (I tried updating some of my repos and it went fine as far as I can tell...)

/Per

[mryndzionek]

Same. The exact error:

error[E0061]: this function takes 6 arguments but 5 arguments were supplied
   --> src/bin/main.rs:5:1
    |
5   | #[rtic::app(device = stm32f1xx_hal::pac, peripherals = true, dispatchers = [PVD, WWDG, RTC, SPI1])]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    | |
    | supplied 5 arguments
    | expected 6 arguments
    |
note: function defined here
   --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rtic-1.1.0/src/export.rs:175:15
    |
175 | pub unsafe fn lock<T, R>(
    |               ^^^^
    = note: this error originates in the attribute macro `rtic::app` (in Nightly builds, run with -Z macro-backtrace for more info)

This is in my opinion due to cortex-m-rtic-macros not being updated to 1.1.0. Shouldn't this be updated to 1.1.0?

[astraw]

As another datum, I'm also seeing this regression.

[perlindgren]

New version coming up shortly (maybe already released).

Please report back so we know if that solved the issue.
/Per

[mryndzionek]

Okay, the reported error has gone, but now I have another one:

error: any use of this value will cause an error
 --> src/bin/main.rs:5:1
  |
5 | #[rtic::app(device = stm32f1xx_hal::pac, peripherals = true, dispatchers = [PVD, WWDG, RTC, SPI1])]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to shift left by `35_u32`, which would overflow
  |
  = note: `#[deny(const_err)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>
  = note: this error originates in the attribute macro `rtic::app` (in Nightly builds, run with -Z macro-backtrace for more info)

The generated code causing the problem:

    } const MASKS : [u32 ; 3] =
    [0 | 1 << stm32f1xx_hal :: pac :: Interrupt :: SPI1 as u32, 0 | 1 <<

SPI1 is 35...

[perlindgren]

The MASKs are only used for the M0/M0++ and they can have only 32 vectors. This code should never be active if not on thumbv7m (m3 and above), so I don't really know why this happens. Could be that the code is generated but not used, and some warning turned into an error.

I'm not by my dev computer so cannot test currently, but I naively assume that the tests should have caught such warnings/errors.

[perlindgren]

you could try just allow this warning for the moment... (we could use an unchecked version in the implementation)

[mryndzionek]

stm32f103 is M3, so thumbv7m, right? If I allow this warning I get a bunch of referenced constant has errors.

[perlindgren]

I guess that's related to the over-shifting. Are these hard errors or just warnings?

[perlindgren]

I assume you have set the target to thumv7m right?

[mryndzionek]

I assume you have set the target to thumv7m right?

yes. I don't see any code that would disable the masks generation on thumbv7m. So it's probably as you've written, it's generated, but not used, but Rust still disallows it. I don't know how to remove those referenced constant has errors errors...

[perlindgren]

I will try fixing it tomorrow then. I guess it slipped through the CI since we are testing on a fake device. I never seen this error, could be that the compiler has become more picky. You could try with an older compiler (but then again some other stuff might fail (at least on stable.)

[Crzyrndm]

Just hit the over-shift lint (STM32L4, M4F target) when trying to run some updates
#[rtic::app(device = stm32l4xx_hal::pac, dispatchers = [TSC, LCD])]
Using interrupts with lower indices resolves the issue for now

[perlindgren]

We are working on a real fix, in the meantime you can try:

#![allow(const_err)]

As seen the problem occurs only in case an interrupt with a vector index >31 is actually used (causing the over-shift in non-used code). Our tests did not cover this edge case, so it slipped by.

Thanks @Crzyrndm and @mryndzionek for the quick and prompt reporting.

/Per

[astraw]

In case it is useful, here is a recipe to reproduce the issue:

git clone https://github.com/strawlab/strand-braid # currently at d7426dea92dab1d312ab9772fc7c1e8c146370e2
cd strand-braid/camtrig-firmware
cargo check # note that compilation succeeds

# Now, manually change `strand-braid/camtrig-firmware/Cargo.toml` such that
# the `cortex-m-rtic` version is set to "1" and remove the explicit requirement on `cortex-m-rtic-macros`.

cargo update
cargo check # note that compilation fails

The error I currently get is the following:

error: any use of this value will cause an error
  --> src\main.rs:66:1
   |
66 | #[rtic::app(device = stm32f3xx_hal::pac, peripherals = true)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to shift left by `38_u32`, which would overflow
   |
   = note: `#[deny(const_err)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>
   = note: this error originates in the attribute macro `rtic::app` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `camtrig-firmware` due to previous error

This is with rustc version 1.60.0 (7737e0b5c 2022-04-04)

[mryndzionek]

I would also like to add that #![allow(const_err)] doesn't help. It just causes a bunch of referenced constant has errors that I don't know how to get rid of.

[perlindgren]

Hmm, strange, @mryndzionek do you have a minimal reproducable example?

[mryndzionek]

Yes, just use the recipe from @astraw above, but run cargo build instead just cargo check.

[korken89]

For now we have yanked the 1.1 release until we get it properly fixed.

[AfoHT]

Did anyone have a go with the released v1.1.2?

I propose we close this issue, but if there's something it is easy to reopen 👍

[astraw]

Yes, I just checked and 1.1.2 works for me. Thanks.

[mryndzionek]

Yes, works for me also.