turn_off_the_borrow_checker in you_can - Rust

Docs.rs

you-can-0.0.14

you-can 0.0.14

Permalink

Docs.rs crate page

MIT OR Apache-2.0

Links

Repository

crates.io

Source

Owners

jeremyBanks

Dependencies

you-can-build-macros ^0.0.14

normal

compiletest_rs ^0.8.0

dev

rustc_version ^0.4.0

dev

Versions

100%
of the crate is documented

Platform

i686-pc-windows-msvc

i686-unknown-linux-gnu

x86_64-apple-darwin

x86_64-pc-windows-msvc

x86_64-unknown-linux-gnu

Feature flags

docs.rs
About docs.rs Badges Builds Metadata Shorthand URLs Download Rustdoc JSON Build queue Privacy policy

Rust

Rust website
The Book
Standard Library API Reference
Rust by Example
The Cargo Guide
Clippy Documentation

turn_off_the_borrow_checkeryou_can0.0.14turn_off_the_borrow_checkerSectionsExampleWithout MacroWith MacroExplanationExpandedExampleDiscussionsIn crate you_canyou_canAttribute Macro turn_off_the_borrow_checker Copy item pathSource #[turn_off_the_borrow_checker]Expand descriptionYou can’t “turn off the borrow checker” in Rust, and you shouldn’t want
to. Rust’s references aren’t pointers, and the compiler is free to
decimate code that tries to use references as though they are. If you need raw
pointer behaviour in Rust, don’t use this, use
Rust’s actual raw pointers, which don’t make the same aliasing guarantees
to the compiler. However, if you would like to pretend the borrow checker
doesn’t exist for educational purposes and never in production code, this
macro that will suppress many (though not all) borrow checker errors in the code
it’s applied to.
This shouldn’t break any otherwise-valid code; the borrow checker doesn’t affect
compilation output, only verify input validity. However, it will allow unsound
and unsafe nonsense that will fail unpredictably and dangerously. This is not
safe to use.
§Example§Without Macro
ⓘfn main() {
let mut owned = vec![1, 32];

let mut_1 = &mut owned[0];
let mut_2 = &mut owned[1];
//~^ ERROR cannot borrow `owned` as mutable more than once at a time

drop(owned);
//~^ ERROR cannot move out of `owned` because it is borrowed
let undefined = *mut_1 + *mut_2;
println!("{undefined}");
}§With Macro
#[you_can::turn_off_the_borrow_checker]
fn main() {
let mut owned = vec![1, 32];

let mut_1 = &mut owned[0];
let mut_2 = &mut owned[1];
//~^ WARNING the borrow checker is suppressed for these references.

drop(owned);
let undefined = *mut_1 + *mut_2;
println!("{undefined}");
}§Explanation
The macro looks for references created in the code by use of the & or &mut
operators or the ref and ref mut bindings, and wraps them with our
borrow_unchecked() function to unbind their lifetimes, causing the
borrow checker to effectively ignore them. If running on nightly, it adds new
warning diagnostic messages for every reference it modifies.
§Expanded
fn main() {
let mut owned = vec![1, 32];

let mut_1 = unsafe { ::you_can::borrow_unchecked(&mut owned[0]) };
let mut_2 = unsafe { ::you_can::borrow_unchecked(&mut owned[1]) };

drop(owned);
let undefined = *mut_1 + *mut_2;
println!("{undefined}");
}
This approached is limited. It can’t suppress errors resulting from the code
illegally composing lifetimes created elsewhere, or references created
implicitly. As a workaround, prefixing &* can sometimes be used to force an
explicit reference where one is needed, such as as in the example below.
§Example
#[you_can::turn_off_the_borrow_checker]
fn main() {
let mut source = Some(1);
let inner_mut = &*source.as_ref().unwrap();
let mutable_alias = &mut source;

source = None;
*mutable_alias = Some(2);

if let Some(ref mut inner_a) = source {
match source {
Some(ref mut inner_b) => {
*inner_b = inner_mut + 1;
*inner_a = inner_mut + 2;
},
None => {
println!("none");
},
}
}

println!("{source:?}");
}§Expanded
fn main() {
let mut source = Some(1);
let inner_mut = unsafe { ::you_can::borrow_unchecked(&*source.as_ref().unwrap()) };
let mutable_alias = unsafe { ::you_can::borrow_unchecked(&mut source) };

source = None;
*mutable_alias = Some(2);

if let Some(ref mut inner_a) = source {
let inner_a = unsafe { ::you_can::borrow_unchecked(inner_a) };

match source {
Some(ref mut inner_b) => {
let inner_b = unsafe { ::you_can::borrow_unchecked(inner_b) };

*inner_b = inner_mut + 1;
*inner_a = inner_mut + 2;
},
None => {
println!("none");
},
}
}

println!("{source:?}");
}§Discussions
Here are some related discussions, mostly about why you shouldn’t do this:

https://reddit.com/s9az4y
https://internals.rust-lang.org/t/16001
https://news.ycombinator.com/item?id=30031323
https://twitter.com/pcwalton/status/1485718602233704452
https://smitop.com/post/rust-skip-borrowck

The `turn_off_the_borrow_checker` macro within the `you-can` crate provides a mechanism to suppress borrow checker errors in Rust, although the documentation strongly advises against its use in production code due to profound safety implications. Rust's system design relies on references not being simple pointers, meaning the compiler actively enforces rules regarding aliasing and lifetimes to guarantee memory safety. The macro permits code to operate outside these guarantees, which fundamentally introduces the potential for unsound and dangerous operations that can lead to unpredictable failures.

The core function of this macro is to suppress many, though not all, borrow checker warnings in the code it annotates. It achieves this by wrapping references with a helper function, `borrow_unchecked()`, which effectively unbinds the lifetimes of those references, allowing the compiler to ignore the rules it would normally enforce. While this allows for the compilation of code that might otherwise be deemed unsafe, it is crucial to understand that this practice sacrifices the compiler's primary role as a safety guarantor. The text emphasizes that the borrow checker's primary function is to verify input validity, and bypassing it permits the execution of code that is inherently unsafe.

The macro operates by targeting references created through the use of the & or &mut operators, as well as ref and ref mut bindings. When applied, the macro compels the code to proceed as if these references do not adhere to the borrowing rules. Although the compiler output remains largely unaffected, the resulting program can contain logical errors related to memory access and state, making it fundamentally unreliable.

The documentation illustrates that simply applying the attribute suppresses certain errors during compilation, but the actual unsafe behavior remains present. For more intricate scenarios, the documentation suggests that this approach is limited when dealing with complex compositions of lifetimes or implicitly created references. As a workaround for these limitations, the documentation notes that prefixing expressions like &* can sometimes be leveraged to force the code to be more explicit about its references, potentially mitigating some issues related to implicit borrowing.

In more advanced examples, the macro necessitates the use of explicit calls to functions like `borrow_unchecked()` to achieve the desired effect of bypassing checks for specific references. This suggests that relying solely on the attribute is insufficient for complex logic; developers must integrate unsafe calls directly where the borrowing rules are deliberately circumvented. The discussion surrounding this feature highlights a philosophical tension in Rust programming: balancing the desire for expressive, low-level control over memory management against the compiler's commitment to compile-time safety. Ultimately, the presented examples and discussions strongly advise that this feature should be reserved only for educational purposes and not employed in any context where reliability and security are paramount.