build!: require rustc 1.85

[esteve]

This PR updates the requirement for the rustc compiler to 1.85.

[luca-della-vedova]

Somewhat tangential to the 1.85 or no 1.85 decision, but this PR and its almost 4000 diff mostly due to format changes will really wreak havoc of merge conflicts in all the PRs that are currently open.

In an ideal world we would get through some of the review backlog and review / merge open PRs first.
Iin a less ideal world we would configure rustfmt to use the previous rust edition and undo format changes here.
In an even less ideal world we would merge this and commit to solve merge conflicts for all open PRs to make contributor's life easier.
In the worst world I can imagine this gets merged as is and now all contributors with long open PRs need to navigate large scale merge conflicts.

[esteve]

@luca-della-vedova yeah, I agree, it's not an ideal situation. I've kept the formatting changes in a separate commit so they can be easily reverted/removed. I'd rather keep the 1.85 requirement given that requiring 1.75 is not providing any benefit and in fact, it's causing issues with some of the dependencies. We could postpone the switch to the 2024 edition, though still keep the code changes (i.e. unsafe blocks).

For the next release of rclrs I want to include at least, your PR with the dynamic publishers/subscribers, the switch to 1.85 and some of the smaller PRs (warnings, QoS, etc). After all those PRs are merged, it'd be a good moment to switch to Rust 2024 and reformat the source code.

However, formatting changes seem to be mostly related to the ordering of the imports, and not much else.

[esteve]

@knmcguire windows is not building because somewhere rustc 1.75 is still being used. I submitted ros2/ros2#1785, but as per your comment https://openrobotics.zulipchat.com/#narrow/channel/526027-ROS-General/topic/rustc.20to.201.2E85.3F/near/567766572, the version of compiler seems to be set somewhere else. Do you know where?

[knmcguire]

Ah that was just a comment for if someone would test your PR in CI before merge, CI will still get the default pixi.toml that is on the rolling branch on ros2 and not from your branch on which your PR is based.

See this part in the CI: https://github.com/ros2/ci/blob/19617b2e6cbdd232c5b5d700f0aa6b8dabbb0328/windows_docker_resources/Dockerfile#L53

So... that is for sure a problem, because if the CI builds it won't be based on your change, also for anyone that will update the pixi.toml in the future and something the infra team would need to look at.

[knmcguire]

How about making our lives easier, and just add the following right after this line in github actions

pixi remove rust  --manifest-path C:\pixi_ws\pixi.toml
pixi add "rust==1.85.0"  --manifest-path C:\pixi_ws\pixi.toml

Either I can make a PR or you can add it as a commit here and directly see the ci.

We just have to remember to at one point make sure that the ci is closer to what ROS2 is doing but let's hope our collective memory will be working ;)

[esteve]

@knmcguire thanks for the idea. I've pushed the fix in 4bbb643

[knmcguire]

so far so good ;) seems to be building

[maspe36]

LGTM