How do I get rid of this warning? My gogglefu didn't help.
You should stop setting this argument.
I didn't. And I can't figure out where this is set.
Maybe in .cargo/config.toml or .cargo/config in your home dir or somewhere inside the project directory?
None of the two. I grepped everywhere I was aware of. It may be some package or ... go figure.
are you using some outdated project template?
I started the project by cloning a template from github, yes. Maybe need to be sure all the crates versions in cargo.toml are updated?
NOTE: checked all the crates' versions in cargo.toml and they are all at last version.
This is my .cargo/config.toml
[target.'cfg(all(target_arch = "arm", target_os = "none"))']
# Choose a default "cargo run" tool (see README for more info)
# - `probe-rs` provides flashing and defmt via a hardware debugger, and stack unwind on panic
# - elf2uf2-rs loads firmware over USB when the rp2040 is in boot mode
runner = "probe-rs run --chip RP2040 --protocol swd"
# runner = "elf2uf2-rs -d"
rustflags = [
"-Z",
"threads=24",
"-C",
"linker=flip-link",
"-C",
"link-arg=--nmagic",
# "-C", "link-arg=-Tlink.x",
"-C",
"link-arg=-Tdefmt.x",
# Code-size optimizations.
# trap unreachable can save a lot of space, but requires nightly compiler.
# uncomment the next line if you wish to enable it
# "-Z", "trap-unreachable=no",
"-C",
"no-vectorize-loops",
]
[build]
target = "thumbv6m-none-eabi"
[env]
DEFMT_LOG = "debug"
And toolchain:
active toolchain
----------------
name: nightly-x86_64-pc-windows-gnu
active because: it's the default toolchain
installed targets:
thumbv6m-none-eabi
x86_64-pc-windows-gnu
My $HOME/.rustup/settings.toml
version = "12"
default_host_triple = "x86_64-pc-windows-msvc"
default_toolchain = "nightly-x86_64-pc-windows-gnu"
profile = "complete"
[overrides]
1 Like
this looks alright.
this config file is not relevant here, do you have a $HOME/.cargo/config.tom file?
also, this is unlikely, but just to be sure, do you have a RUSTFLAGS envrionement variable set by any chance?
Negative.
Negative.
it's strange. the command line flag must come from somewhere.
does this warning show up only for this specific project, or does it show up for all projects?
Yep. It looks like coming out of nowhere. That's why I'm searching for help in the forum, it's weird.
All projects, I suppose.
I created a new project with "cargo new testing", then copied in the memory.x file (ie: it's embedded, so I need that for the linker to be happy), added minimal crates and minimal main code
[package]
name = "testing"
version = "0.1.0"
edition = "2024"
[dependencies]
defmt = "1"
defmt-rtt = "1"
panic-probe = { version = "1.0.0", features = ["print-defmt"] }
cortex-m-rt = { version = "0.7.5" }
rp2040-hal = { version = "0.11.0", features = [
"rt",
"critical-section-impl",
"defmt",
] }
#![no_main]
#![no_std]
use panic_probe as _;
use rp2040_hal as hal;
use hal::pac;
use defmt_rtt as _;
#[rp2040_hal::entry]
fn main() -> ! {
defmt::timestamp!("Starting MyProgram...");
let mut _pac = pac::Peripherals::take().unwrap();
loop {}
}
Booom, same result.
warning: `-C inline-threshold`: this option is deprecated and does nothing (consider using `-Cllvm-args=--inline-threshold=...`)
warning: `testing` (bin "testing") generated 1 warning
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.20s
does it happen only for cross compiled target, or it also happens for native target?
another shot in the dark, have you happened to set the environment variable RUSTC or RUSTC_WRAPPER?
I'm not very comfortable with Windows but the command gci env: from vscode terminal (ie: the same terminal I use for cargo build) reports no env vars named RUSTsomething
Using msvc toolchain instead of gnu toolchain gives the same results:
Compiling rp2040-pac v0.6.0
Compiling debug-helper v0.3.13
Compiling futures-core v0.3.31
Compiling pin-utils v0.1.0
warning: `-C inline-threshold`: this option is deprecated and does nothing (consider using `-Cllvm-args=--inline-threshold=...`)
warning: `bitflags` (lib) generated 1 warning (1 duplicate)
Compiling nb v0.1.3
warning: `pin-utils` (lib) generated 1 warning (1 duplicate)
It's strange some crates spit the same warning and others don't.
Bingo!
fn main() {
println!("Hello, world!");
}
for both x86_64-pc-windows-gnu and x86_64-pc-windows-msvc targets spit no warning (and the exe runs).
There's something wrong with the thumbv6m-none-eabi target, I suppose. Or in some of the "mandatory" crates for my platform. The question now is how to pin down the offender.
The thing that disturbs me is having that thing getting out of nothing. There's some hardcoding somewhere.
that's very unlikely from the compiler itself, it's more likely some crate is doing weird stuff (e.g. in build script or procedural macros).
you can add -vv to cargo command and examine how rustc was invoked. maybe that will give you some clue.
There's an -C inline-threshold=5 added close to the end of the command. That's the offending bit but ... why is it there?
If I add
"-C",
"--inline-threshold=0",
to my .cargo/config.toml both my option and the magic one pop out in the rustc command, and the warning gets duplicated (ie: 2 warnings per crate built). I don' know how the toolchain works but it seems relevant to me.
I spent some time for cleaning up my system. I had a ton of SDK, GUIs, runtimes, ... uninstalled, deleted leftovers and so on. Among the stuff I erased there was also a .cargo folder in the root of the hdd, having the arm toolchain as target. Probably, because of some nasty folder traversal and inheritance of properties, that was the problem, as I always had problems installing any host tool (ex: cargo-generate, probe-rs, and so on), unless I specified the x86 toolchain. Basically the arm toolchain was the default on the whole system ...
It works good now. Thanks for helping.
2 Likes
wow, that's really unusual situation. although this is actually the documented behavior (see Configuration - The Cargo Book), I find it unintuitive, or surprising to say the least. I guess it's because cargo searches for the workspace root directory and the configuration file independently.
I think it would make more sense if the traversal to parent directory were confined within the workspace, but I don't know cargo would make such change.
to be fair, your situation is rather unusual: people typically put per-project configurations in the workspace root, and global configurations in $CARGO_HOME, it's very rare that some toolchain puts the configuration at the root of a harddisk (or partition) that is outside of any projects, or the global $CARGO_HOME.