Skip to content

Is rustc --emit=<type>=<path> supported? #30204

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

Closed
pnkfelix opened this issue Dec 4, 2015 · 9 comments
Closed

Is rustc --emit=<type>=<path> supported? #30204

pnkfelix opened this issue Dec 4, 2015 · 9 comments

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Dec 4, 2015

There seems to be code hanging around to support a variant of --emit of the form --emit=<type>=<path>.

Its not clear what it is supposed to do.

I suspect it was meant to be a way to indicate a specific file name to use for an output (so that one could do e.g. rustc --emit asm=bar.s --emit obj foo.rs to get machine code in foo.o (inferred) and assembly in bar.s (explicitly specified).

But if that's the intention, it does not seem to work currently. (Which is fine because the option is undocumented anyway.)

@pnkfelix
Copy link
Member Author

pnkfelix commented Dec 4, 2015

(or is it somehow meant to be used as an input filename? )

@pnkfelix
Copy link
Member Author

pnkfelix commented Dec 4, 2015

cc @alexcrichton

@alexcrichton
Copy link
Member

Yeah this was added recently to make dep-info emission more customizable and I tried to add some docs for it but our man pages are actually pretty rarely read I think...

We've also got what I was hoping was a pretty exhaustive test for this sort of functionality, and when I run rustc --emit asm=bar.s --emit obj foo.rs it works for me? (nightly channel right now)

When you say that it doesn't work, what sort of behavior did you see?

@pnkfelix
Copy link
Member Author

pnkfelix commented Dec 4, 2015

@alexcrichton oh maybe I wasn't testing against nightly; let me double check

@pnkfelix
Copy link
Member Author

pnkfelix commented Dec 4, 2015

@alexcrichton I think I know the problem: I'm using --emit=asm=bar, not --emit asm=bar

Update: /me goes off to review what getopts is specified to do in such cases

@alexcrichton
Copy link
Member

Oh weird, I would expect getopts to consider those two equivalent... I wonder if there's a bug in getopts?

@pnkfelix
Copy link
Member Author

pnkfelix commented Dec 4, 2015

@alexcrichton yes I think it is, I just saw something suspicious; look here:

https://github.com/rust-lang/rust/blob/master/src/libgetopts/lib.rs#L605

(I bet the split above it should be a splitn...)


Update:

Yeah, compare it against the version that is hosted on crates.io, which does use splitn at the analogous spot:

https://github.com/rust-lang-nursery/getopts/blob/master/src/lib.rs#L338

@alexcrichton
Copy link
Member

Ah yep that'd do it!

@pnkfelix
Copy link
Member Author

pnkfelix commented Dec 4, 2015

I'm cherry-picking rust-lang/getopts@8ec916b as we speak. :)

pnkfelix added a commit to pnkfelix/rust that referenced this issue Dec 4, 2015
bors added a commit that referenced this issue Dec 5, 2015
…ichton

Fix internal `getopts` so `--a=b=c` acts like `--a b=c` rather than `--a b`.

Fix #30204
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

No branches or pull requests

2 participants