Changed objects files extension to "obj" on windows

[liranringel]

Solves this issue:
#37207

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[hanna-kruppe]

Does this not trigger a dead code warning for one of the two arms depending on target_os?

[eddyb]

This doesn't feel right, I'd expect to use the target OS not the host one (of the rustc in use).
That is, this won't use .obj for cross-compilation and that seems wrong to me.

[liranringel]

@rkruppe I made a simple program that checks that. It didn't trigger a dead code warning.
@eddyb I agree. I'll see how it can be done.

[liranringel]

I'd liked to pass Session and use the sess.target.target.options.target_family, but Session is not Sync, and It cannot be sent in run_work_multithreaded.
I wonder how should I pass that information (because it will has to be sent to many functions, so I want it to be part of something like WorkItem or CodegenContext).

[eddyb]

You may be able to clone TargetOptions (or whatever the type is called)? That or pre-compute the file names. cc @rust-lang/compiler

[liranringel]

@eddyb Oh, it could be part of TargetOptions. Is there a reason that Object is part of OutputType, and TargetOptions (which has exe_suffix, staticlib_suffix...) does not simply have obj_suffix?

[eddyb]

I don't think so? Those suffixes seem like the natural place for this though.

[eddyb]

r? @alexcrichton

[nagisa]

The appropriate fix would be to add a field to the target options, similar to the dll_prefix and dll_suffix.

[alexcrichton]

Thanks for the PR @liranringel! I fear, though, that the ship may have sailed on this at this point. Although "obj" may be the more correct suffix, today object files are emitted with "o" and tools can be relying on that. I fear that changing this will be a breaking change that would be difficult to work with externally. With that breakage, and with what I believe aren't strong technical reasons to make this change, I'm tempted to leave as-is.

[liranringel]

Ok, then we should close the issue.

[retep998]

Also, this only needs to produce a .obj for Windows msvc, not Windows in general. I'd be very interested in what sort of tooling or automation relies on .o for the msvc targets specifically. Can we at least do some sort of investigation into what out there actually would be broken, instead of just immediately giving up?

[alexcrichton]

@liranringel ok I'll close this for now. @retep998 want to track that on the tracking issue?

[retep998]

I updated the tracking issue with more information.