Don’t change semantic behaviour based on debug_assertions
#1882
Conversation
This should hopefully not be a breaking change, as the same code could produce the same behaviour if compiled with different flags, and the semantic meaning of the resulting configuration should be the same. But Hyrum’s law is always lurking… Closes: GitoxideLabs#1881
This should hopefully not be a breaking change, as the same code could produce the same behaviour if compiled with different flags. However, it’s possible some downstream test suites could be affected and will need to opt in to the feature.
|
Test failures seem unrelated. |
```
Run dtolnay/rust-toolchain@stable
Run : parse toolchain version
Run : construct rustup command line
Run : set $CARGO_HOME
Run : install rustup if needed
info: downloading installer
error: $HOME differs from euid-obtained home directory: you may be using sudo
error: $HOME directory: /github/home
error: euid-obtained home directory: /root
info: profile set to 'default'
info: default host triple is x86_64-unknown-linux-gnu
info: skipping toolchain installation
Rust is installed now. Great!
To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).
To configure your current shell, you need to source
the corresponding env file under $HOME/.cargo.
This is usually done by running one of the following (note the leading DOT):
. "$HOME/.cargo/env" # For sh/bash/zsh/ash/dash/pdksh
source "$HOME/.cargo/env.fish" # For fish
source "$HOME/.cargo/env.nu" # For nushell
Run rustup toolchain install stable-i686-unknown-linux-gnu --profile minimal --no-self-update
rustup toolchain install stable-i686-unknown-linux-gnu --profile minimal --no-self-update
shell: bash --noprofile --norc -e -o pipefail {0}
env:
CARGO_TERM_COLOR: always
CLICOLOR: 1
CARGO_HOME: /github/home/.cargo
error: toolchain 'stable-i686-unknown-linux-gnu' may not be able to run on this system
note: to build software for that platform, try `rustup target add i686-unknown-linux-gnu` instead
note: add the `--force-non-host` flag to install the toolchain anyway
```
Byron
force-pushed
the
push-ylwwuwymlmwt
branch
from
dd043ce to
cff37cd
Compare
|
@EliahKagan It seems the test-32bit job is failing at least temporarily so I removed it from the 'needed to auto-merge' list. For now I didn't investigate what's going on there and probably won't get to it anytime soon. Edit: there were also new Windows failures (unfortunately), which I put into the list of expected failures for now. Edit2: Apologies, @EliahKagan , I realize that all of these issues are already fixed with PRs waiting, and I should rather have processed my emails in order a little more. Even though this will merge, I will merge all of your pending PRs next and fix merge-conflicts should they arise after this PR merges. |
Maybe this changed due to a new Git for Windows version, but I didn't investigate.
|
@Byron The The But I think it's fine to put that off until some point after this PR is merged. The jobs can be put back as dependencies of Also, #1878 and #1879 were for two of the RUSTSEC advisories that caused |
@Byron Now that this is merged, I can rebase and update Edit: I've done that, and they should be ready. See #1870 (comment) and #1874 (comment). I hope this is all right. Edit 2: I've confirmed that #1878 and #1879 are superseded by changes added here and that those PRs can therefore be closed without merging. Accordingly, I have closed #1879. But I cannot myself close #1878. |
Now that this repository is in an organization, permissions are much more fine-grained. If you have suggestions on how to make your life easier, I'd be happy to make adjustments. |
Thanks--I've opened #1883 to ask if the ability to interact with Dependabot is something that can and should be delegated. (That is, I have moved this aspect of the conversation from here to that new question, in case it becomes complex.) |
The `huamntime` crate briefly had unmaintained status, for which RUSTSEC-2025-0014. It has since become maintained again, and that advisory has been withdrawn, so this removes it from the list of advisores we allow `cargo deny` to ignore. Background: - https://rustsec.org/advisories/RUSTSEC-2025-0014.html (advisory) - rustsec/advisory-db#2249 (issued) - rustsec/advisory-db#2252 (withdrawn) - cf7f34d in GitoxideLabs#1882 (commit that ignored it, among other changes)
The `humantime` crate briefly had unmaintained status, for which RUSTSEC-2025-0014 was issued. It has since become maintained again, and that advisory has been withdrawn. So this removes it from the list of advisores we allow `cargo deny` to ignore. Background: - https://rustsec.org/advisories/RUSTSEC-2025-0014.html (advisory) - rustsec/advisory-db#2249 (issued) - rustsec/advisory-db#2252 (withdrawn) - cf7f34d in GitoxideLabs#1882 (commit that ignored it, among other changes)
I believe these are the only two cases where release builds are conditioned on for something other than actual debug checks. Let me know if you want to add more exclamation marks to these commit messages; compiler‐flag‐dependent things are kind of borderline for breaking‐change‐ness in my view.
Closes: #1881