-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Convert rust_log.cpp to Rust, closes #8703 #8880
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for tackling this! I love removing C++. |
Thanks for the feedbacl @brson All functionality from rust_log.cpp should be ported to Rust now. I've added a couple of unit tests as well. The Rust implementation should give slightly better error messages than the c++ version, if a log level in RUST_LOG isn't a valid integer. |
assert_eq!(dirs[2].level, 4); | ||
} | ||
|
||
#[cfg(test)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you wrap all these tests in a #[cfg(test)] mod tests { ... }
module? That way you don't need #[cfg(test)]
on all the functions and it's also easy to see where the tests start and end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#[test]
implies #[cfg(test)]
, fwiw. Wrapping tests in a module is nice because it makes it easier to scope test-only uses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to do that, but parse_loggin_spec and update_entry aren't public.
Is there a way to use private functions in a module in the same file?
Thanks for the feedback @alexcrichton, I hope I addressed all your comments. I could work on #6031 and #6033, but it seems like @novalis started working on them already? |
} | ||
|
||
// This is the Rust representation of the mod_entry struct in src/rt/rust_crate_map.h | ||
struct ModEntry{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually a really-dangerous version of the mod_entry
struct. Because this is C FFI, we can't assume that char*
== ~str
, so I think that this would be more appropriately written as
struct ModEntry {
name: *c_char,
log_level: *u32, // note the '*', this is important for the log level to actually get set.
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the main problems as-is is that if you drop the structure (if it didn't materialize through an &
pointer), it would attempt to free name
, leading to lots of pain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does log_level have to be a pointer?
Shouldn't a normal value be enough, because its accessed and modified via a pointer to the struct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what it's defined to be in the header file in C++. I think that we create a global in LLVM with some random name and then shove a pointer to the global in the mod_entry struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I overlooked that!
Should be fixed now
Also, I think it's best to hold of the extra issues for later pull requests. Looks like we've got those taken care of :) |
@alexcrichton thanks for the extensive feedback and your patience. I've updated the pointer related stuff, but I had to use to_c_str and transmute to set up the test data (not sure if there's a nicer way to test it) |
No problem at all! Thanks for putting up with me :) Once the |
I've started working on #8703. RUST_LOG="::help" should work, I hope I'll be able to finish the rest this weekend.
Thanks, and nice work! |
I was thinking about converting rust_crate_map.cpp to Rust as well. That would simplify src/libstd/rt/logging.rs as well, because we could get rid of the code for calling a rust closure in c++. But I couldn't find the place were the crate map is initialized and that would be very helpful as a starting point. |
It's actually static data in the executable that gets passed to the #[start]
fn start(argc: int, argv: **u8, crate_map: *u8) -> int The crate map is created and added to the binary in |
Thanks for the hint, I'm looking into rewriting rust_crate_map.cpp and I'll open a pull request as soon as I have something presentable |
This patch converts the rust_crate_map.cpp to Rust as mentioned at the end of #8880.
Add some testcases for recent rustfix update changelog: none This adds a testcase for a bugfix that has been fixed by https://github.com/rust-lang/rustfix/tree/v0.6.1 `rustfix` is pulled in by `compiletest_rs`. So to test that the correct rustfix version is used, I added one (and a half) testcase. I tried to add a testcase for rust-lang#8734 as well, but interesting enough the rustfix is wrong: ```diff fn issue8734() { let _ = [0u8, 1, 2, 3] .into_iter() - .and_then(|n| match n { + .flat_map(|n| match n { + 1 => [n + .saturating_add(1) 1 => [n .saturating_add(1) .saturating_add(1) .saturating_add(1) .saturating_add(1) .saturating_add(1) .saturating_add(1) .saturating_add(1) .saturating_add(1)], n => [n], }); } ``` this needs some investigation and then this testcase needs to be enabled by commenting it out closes rust-lang#8878 related to rust-lang#8734
I've started working on #8703.
RUST_LOG="::help" should work, I hope I'll be able to finish the rest this weekend.