edition support

[mfarrugi]

bazelbuild/rules_rust#157

without rules_rust changes, raze can emit --edition 2018 as needed

[acmcarther]

I think we need to take this information from the individual crates. We can't assume that an arbitrary crate is 2018 compatible.

[vitalyd]

@acmcarther (or anyone else, really), how involved is adding --edition support? Naively, I'd imagine this shouldn't be too bad: propagate cargo manifest's edition value, if present, to the generated BUILD file. I suppose while bazelbuild/rules_rust#157 is still open, raze can add the edition as a rustc_flags argument.

Is that accurate? If so, any idea when the support might be added? Sorry, I'm not entirely sure how this project is maintained.

Thanks

[acmcarther]

Sorry for the delay on this. I haven't been able to set aside much time recently to hash this out.

Edition is a new field in SerializedTarget. This field is supposed to be one to one with our metadata::Target .

This field ought to be automatically populated by the cargo metadata codepath (CargoSubcommandMetadataFetcher), but will need to be added to the internals-using codepath (CargoInternalsMetadataFetcher): the target section is here:

cargo-raze/impl/src/metadata.rs

Lines 304 to 310 in 1a79366

	targets.push(Target {
	name: target.name().to_owned(),
	kind: util::kind_to_kinds(target.kind()),
	crate_types: crate_types,
	src_path: target.src_path().display().to_string(),
	});
	}

... I would have liked to add where this information is available in the resolved package, but I don't have any more time this morning to look into this.

If you're interested in implementing it, I would be very happy to review a pull request. Else, you're unfortunately beholden to my flakiness. I'll make a concerted effort to work on this item soon given its relevance in the recently released 1.31.0

[mfarrugi]

And with pacman82/atoi-rs@5863397#diff-80398c5faae3c069e4e6aa2ed11b28c0 I've run into this as a problem :)

For now it sufficed to pin the dep to the previous version.