Skip to content
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

Implemented string lookup for build.rustflags config key #3356

Merged
merged 4 commits into from
Dec 3, 2016

Conversation

ibabushkin
Copy link
Contributor

This addresses the immediate issue described in #3052 .
I am, however, unsure about the current state of the deeper issues mentioned in that issue, but if needed, I can take stab at them as well. :)

@rust-highfive
Copy link

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member

Looks good to me, thanks! Could you add a test for this as well?

@ibabushkin
Copy link
Contributor Author

Sure, will do!

Also, it would make sense to allow for the same syntax in the target.<...> section, I think I'll add that as well.

@ibabushkin ibabushkin force-pushed the feature-build-rustflags branch from 675256b to 79924b5 Compare December 1, 2016 20:32
@ibabushkin
Copy link
Contributor Author

ibabushkin commented Dec 1, 2016

While building the test case, I noticed that some moving part outside of cargo is doing config file validation, killing the process with an error message before my code runs:

error: invalid configuration for key `build.rustflags`
expected a list, but found a string for `build.rustflags` in /path/here

I'll look into it now.

EDIT: It is indeed a part in cargo, but the message shouldn't be printed, given we want to retry with a different lookup.

@alexcrichton
Copy link
Member

Oh I think it's the get_list(key)?, you'll want to change that to handle the error by looking up a string instead

@ibabushkin
Copy link
Contributor Author

ibabushkin commented Dec 1, 2016

Yes, I figured as much :). Still needs a way to generate a better error message signalling the user can use both strings and lists.

It will probably be somewhat longer and less elegant, however.

@ibabushkin
Copy link
Contributor Author

Hm, after fiddling around with the code a bit, I think this is the cleanest implementation:

    match config.values()?.get(&key) {
        Some(&ConfigValue::String(ref arg, _)) => {
            return Ok(arg.split(' ').map(str::to_string).collect());
        },
        Some(&ConfigValue::List(ref args, _)) => {
            let args = args.into_iter().map(|a| a.0.clone());
            return Ok(args.collect());
        },
        Some(value) => return config.expected("list or string", &key, value.clone()),
        None => (),
    }

@alexcrichton
Copy link
Member

Ah I prefer to use get_string and get_list wherever possible as it works with the env vars (where the values() method doesn't right now

@ibabushkin
Copy link
Contributor Author

Yes, that's indeed a pitfall. I guess it won't work without a third lookup for the value, however, if we want a custom error message (which I think would make sense). Or I could implement something like get_string_or_list with all the functionality as in get_string and get_list and use that, but I'm not sure whether that's worth it, given that there would be only these two calls to it. It might prove handy in the future, however.

@alexcrichton
Copy link
Member

Oh runtime we don't really have to worry about here, just errors and such.

* One of the tests still doesn't pass, this needs further investigation
@alexcrichton
Copy link
Member

Looks good to me, thanks! Want to go ahead and refactor this to perhaps get_list_or_maybe_string or something like that?

@ibabushkin
Copy link
Contributor Author

Sure. I also still need to figure out the details around the second test failing.

@ibabushkin
Copy link
Contributor Author

This should, when passing all tests, be a complete solution in my book ^^.

@alexcrichton
Copy link
Member

@bors: r+

Thanks!

@bors
Copy link
Contributor

bors commented Dec 2, 2016

📌 Commit f440704 has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Dec 2, 2016

⌛ Testing commit f440704 with merge 4aef11e...

@bors
Copy link
Contributor

bors commented Dec 2, 2016

💔 Test failed - status-appveyor

@alexcrichton
Copy link
Member

alexcrichton commented Dec 2, 2016 via email

@bors
Copy link
Contributor

bors commented Dec 2, 2016

⌛ Testing commit f440704 with merge c2852b1...

@bors
Copy link
Contributor

bors commented Dec 2, 2016

💔 Test failed - status-travis

@alexcrichton
Copy link
Member

@bors: retry

@bors
Copy link
Contributor

bors commented Dec 2, 2016

⌛ Testing commit f440704 with merge f33b7b0...

bors added a commit that referenced this pull request Dec 2, 2016
Implemented string lookup for `build.rustflags` config key

This addresses the immediate issue described in #3052 .
I am, however, unsure about the current state of the deeper issues mentioned in that issue, but if needed, I can take stab at them as well. :)
@bors
Copy link
Contributor

bors commented Dec 3, 2016

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing f33b7b0 to master...

@bors bors merged commit f440704 into rust-lang:master Dec 3, 2016
@ibabushkin
Copy link
Contributor Author

Thanks for having me!

@ehuss ehuss added this to the 1.15.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants