So, laced throughout alloc and std methods are marked with #[cfg(not(no_global_oom_handling))], primarily methods that perform allocations where the case of running out of memory is handled via panicking. I've been researching all morning on how to use alloc with that flag enabled. I've gone down a few rabbit holes, such as build-std, but I've come up blank.
Note: I'm aware of the implications; this isn't a question of if I should or shouldn't, only a question of how to enable no_global_oom_handling?
Does anyone know how actually to enable this feature? I'm surprised it's not documented everywhere, even its tracking issue.
You would need to pass a --cfg option. Either as arguments if using rustc directly, or in a RUSTFLAGS environment variable or build.rustflags configuration option in .cargo/config.toml when using Cargo.
An example (including build-std):
RUSTFLAGS="--cfg no_global_oom_handling" cargo +nightly run -Z build-std
See also: How to set cfg options to compile conditionally?
Related
I want to extract all nightly features used by a crate for some research purposes.
Just to be clear, "nightly features" means codes like #![feature(...)]", but not crate provided optional features.
I tried using regex, and it works, but not accurate enough. cfg defined features may not be detected: #![cfg_attr(target_os = "macos", feature(...))].
So I turn to rustc compiler, I wish to modify some source code and print out what features crate uses. Now I'm still trying to find out how rustc deals with nightly features.
I hope someone can give me some tips and help about the process of rustc dealing with nightly features. I'm almost lost in codes.
Access to enabled features is done via rustc_session::Session::features. You can add code after they are set in rustc_interface, or look at how they're computed.
If you are at a later stage, you probably have access to the Session of the compiled crate. For example, TyCtxt has a sess() method (but also a features() method for direct access using the query system), and InferCtxt has a tcx member to access the TyCtxt.
The program I have ends up using over 110 crates in its build. However, the core performance gains (where 80+%) of the benefit is, resides in only a few 'crates'. Ya, I took the time to drill down through crates that used crates. Consequently, I'd like the linker to use lto options for only those 5-6 crates, rather that looking at all +110. Does anyone know if this is possible? And, if it is, how do I direct the linker to do it? Yes, the difference is just build-time, but its only going to get worse as I add more crates.
The unused imports and dead code warnings are the most common that I've found while learning Rust, and they get annoying after awhile (a very short while, like a few seconds). Especially when they are mixed with compiler errors, because it makes the console difficult to read.
I was able to turn off these warnings:
#![allow(unused_imports)]
#![allow(dead_code)]
This will disable the warnings for all builds, but I want the warnings enabled for release builds.
I tried disabling them like this:
#![cfg(dev)]
#![allow(unused_imports)]
#![allow(dead_code)]
But, this removed the entire Rust file from release builds (not what I want).
I tried to configure using cfg_attr but it had no effect for either builds.
#![cfg_attr(dev, allow(unused_imports))]
#![cfg_attr(dev, allow(dead_code))]
I have Googled and read all the related questions on StackOverflow but can't figure this out.
dev isn't a supported predicate for conditional compilation, so your examples will never include the affected code. As far as I know, the best way to detect debug mode is instead with #[cfg(debug_assertions)]. With my testing, #![cfg_attr(debug_assertions, allow(dead_code, unused_imports))] seems to work to disable the lints for debug builds but enable them in release builds.
You can see a list of supported predicates in the Rust reference.
I want to make some changes in libstd and then test them with a toy program. It looks like I can build libstd.so by going to rust/src/libstd and doing a (nightly) cargo build. Once I've done that, how do I get a toy program to build with that libstd instead of the regular version installed on my system?
There are two possibilities in my mind.
Build the compiler from source everytime
Download the Rust source
Make your changes to std
Follow the steps for building from source
Pass an option to rustc that modifies it search path
Run rustc --help
The first two options (--cfg SPEC or -L [KIND=]PATH) are probably were you would point rustc to your version of the std.
I am not very sure how this would work. Ideally someone more knowledgeable could answer this part, because I think it is the preferred solution and way easier.
I am building a makefile for an SDL/OpenGL program. In looking at the Makefile for the SDL2.0 examples, I see compiler flags such as DHAVE_OPENGL, and D_REENTRANT. Nowhere in the man pages for gcc can I find information on either of these flags. Where on the internet/my system can I find documentation about all the flags supported by gcc?
the -D option is used not to define specific compiler flags but to pass macro definitions to the preprocessor.
Indeed -DHAVE_OPENGL is like having #define HAVE_OPENGL 1 in your source code. So they are not related to the compiler per se but just on the code you are compiling.
Here you can find a comprehensive documentation of GCC options in any case.
Those are not compiler flags per-se. -D is a compiler flag, but what follows is a pre-processor definition. You will not find any information on what those mean in the compiler docs because it affects the behavior (e.g. which portions of the code are actually included during compilation) of the actual code that you are building.
So unfortunately, the only way you will know what defining those pre-processor tokens will do is if you investigate the source code you are compiling or if the library you are using documents them.
Generally speaking however, HAVE_OPENGL lets SDL know to compile GL-related code.
Re-entrancy is used for thread safety, and although _REENTRANT is not a standard pre-processor definition (though commonly used with some C stdlib implementations), it is safe to assume that it will cause your software to select re-entrant versions of functions whenever possible.