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

Add support for 'required-features'. #69

Merged

Conversation

little-arhat
Copy link
Contributor

@little-arhat little-arhat commented Aug 23, 2018

Discover 'required-features' in Cargo manifest and initialize value of 'rust-cargo-features'. Fixes #68.

Copy link
Member

@fmdkdd fmdkdd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call on making an alist. It's probably more readable that way with multiple features.

Do you think you could add a test that gets the required-features from a cargo project?

flycheck-rust.el Outdated
kind (lib, bin, test, example or bench), and NAME the target
name (usually, the crate name). If FILE-NAME exactly matches a
target `src-path', this target is returned. Otherwise, return
Return a alist ((KIND . k) (NAME . n) (REQUIRED-FEATURES . rf))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Return an alist

flycheck-rust.el Outdated
Return a alist ((KIND . k) (NAME . n) (REQUIRED-FEATURES . rf))
where KIND is the target kind (lib, bin, test, example or bench),
NAME the target name (usually, the crate name), and REQUIRED-FEATURES is the
optional list of features required to build selected target. If FILE-NAME
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to build the selected target

tests/test-rust-setup.el Show resolved Hide resolved
@little-arhat little-arhat force-pushed the feature-required-features-support branch from 6538525 to 24e0edd Compare August 24, 2018 19:52
@little-arhat
Copy link
Contributor Author

@fmdkdd yeah, sure! Didn't want to add more code for tests without knowing it looks more or less ok %)

Thanks for comments, fixed.

@little-arhat
Copy link
Contributor Author

Hm, tests are failing since cargo there doesn't have "required-features" in cargo metadata output. Should I modify test suite to compare against either alist with required-features or the old one?

@fmdkdd
Copy link
Member

fmdkdd commented Aug 27, 2018

Shouldn't the nightly cargo already emit required-features? Looks like the cargo version is trailing behind:

cargo 1.29.0-nightly (6a7672ef5 2018-08-14)

The test will break for beta and stable, but should eventually get there. In the meantime, we should skip it for older versions. We can (signal 'buttercup-pending "requires cargo 1.29") to mark the test as pending. We could do that after inspecting cargo --version.

@little-arhat little-arhat force-pushed the feature-required-features-support branch from 24e0edd to bb78041 Compare August 27, 2018 22:05
@little-arhat
Copy link
Contributor Author

@fmdkdd yeah, it's lagging behind rustc, not sure what the actual release schedule cargo has. Anyways, it should hit nightly channel soon and then tests will pass for nightly. For other channels I've added check that disables tests for older cargos.

Thanks!

@little-arhat little-arhat force-pushed the feature-required-features-support branch 4 times, most recently from 4ba335f to 934bcb2 Compare August 28, 2018 08:41
Copy link
Member

@fmdkdd fmdkdd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I have some stylistic changes, and one question about the actual version number. See the review comments.

:to-equal '((kind . "lib") (name . "lib-test"))))

(it "'src/main.rs' to the bin target with required-features (fea1)"
(if (cargo-older-than-1.29-nightly)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to use when instead of an empty then branch in the if.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, will fix!


(defun get-cargo-version ()
(let ((cargo (funcall flycheck-executable-find "cargo")))
(with-temp-buffer
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with-output-to-string would be shorter here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was looking for smth like that, cool, thanks.


(defun cargo-older-than-1.29-nightly ()
(let* ((version-parts (cargo-version))
(version (car version-parts))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be shortened with:

(pcase-let ((`(,version ,channel) (cargo-version)))
   ...)

(let* ((version-parts (cargo-version))
(version (car version-parts))
(channel (cadr version-parts)))
(if (version< version "1.29")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More idiomatic would be:

(or (version< version "1.29")
    (and (version= version "1.29") (string= channel "beta")))

But wait, the name of the function implies we return t when cargo --version is more than 1.29-nightly, but we actually do the reverse. This should be fixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Function name is cargo-version-is-older-than-1.29, so for 1.28.0 it will return t (1.28.0 came out before 1.29.0, so it's older). Perhaps "older" is a bit confusing?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Argh, excuse the brainfart. older is not confusing at all, I was just confused.

(channel (cadr version-parts)))
(if (version< version "1.29")
t
(and (version= version "1.29") (string= channel "beta")))))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually know which version required-features will be included in? If it's 1.30, then we don't need to check for the channel, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current beta has cargo 1.29.0-beta (<sha> 2018-08-05) (or some such). Nighty should get this feature in a week at most, and the version will be 1.29.0-nightly (<sha> 2018-08-21). We can just test for 1.30, but then we will disable test for nightly 1.29 even though cargo will have new feature.

Not a big deal, I guess, and will help make code a bit nicer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sure, let's test with 1.29-nightly. No big deal.

Discover 'required-features' in Cargo manifest and initialize value of
'rust-cargo-features'.
@little-arhat little-arhat force-pushed the feature-required-features-support branch from 934bcb2 to 7e491e9 Compare August 28, 2018 19:01
@little-arhat
Copy link
Contributor Author

Apparently, cargo is not bumped automatically for nightly channel, but PR has been posted, so it should be available in next nighly!

@fmdkdd do you have any other comments I should address? %)

@fmdkdd fmdkdd merged commit f1220cc into flycheck:master Sep 4, 2018
@fmdkdd
Copy link
Member

fmdkdd commented Sep 4, 2018

Apparently, cargo is not bumped automatically for nightly channel,

Interesting! Thanks for keeping us posted.

do you have any other comments I should address?

Nope, LGTM. Good job and thank you for the contribution. 👏

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.

2 participants