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

Fix issue #1258 #1312

Closed
wants to merge 2 commits into from
Closed

Fix issue #1258 #1312

wants to merge 2 commits into from

Conversation

bombless
Copy link

Fix #1258
Retry for up to 3 times, as @retep998 suggests

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wycats (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. 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 CONTRIBUTING.md for more information.

@bombless
Copy link
Author

The problem itself is hard to reproduce, so I'm not sure there's good way to test the change.

@wycats
Copy link
Contributor

wycats commented Feb 15, 2015

@bombless it seems like this error should be formatted in the same way as the other status messages. Can you do that?

@bombless
Copy link
Author

@wycats Okay, done. Is it good enough now?

});
for _ in 0 .. 3 {
if path.is_ok() { break }
try!(self.config.shell().status("Refetching", package));
Copy link
Author

Choose a reason for hiding this comment

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

Maybe try!(self.config.shell().error(format!("Refetching {}", package))); is a better idea.
I'm not sure if this should be considered an error or normal status, @wycats .

Copy link
Author

Choose a reason for hiding this comment

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

Or maybe try!(self.config.shell().warn(format!("Refetching {}", package)));

Copy link
Author

Choose a reason for hiding this comment

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

Now I think we could use Downloading(1), Downloading(2), etc, to represent retrying.

@bombless
Copy link
Author

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned wycats Feb 21, 2015
@alexcrichton
Copy link
Member

Hm I'm not sure that this is the best way to go about this. I would not expect that we would try by default to retry downloads of a crate. Additionally, this is discarding all information about the error which happened, possibly retrying for cases which will obviously never succeed. I think that #1258 specifically should be fixed by #1333 instead of retrying.

Thanks for the PR though!

github-merge-queue bot pushed a commit that referenced this pull request Feb 28, 2025
…15245)

### What does this PR try to resolve?

GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+
compared to the previous Windows 11 SDK 10.0.22621, which bumped the
UCRT headers. The new UCRT headers use SSE2 types. However, `cc`
versions <= 1.2.15 emit `/arch:IA32` for `x86` Windows targets for
`clang-cl`, which causes compilation errors since `clang-cl` can't find
SSE2 types without `/arch:SSE2` specified (or defaulted). (Note that
MSVC at the time of writing silently accepts and emits instruments for
code using SSE2 types, as opposed to `clang-cl` hard error-ing).

`cc` 1.2.16 contains a fix for this problem,
rust-lang/cc-rs#1425, to correctly emit
`/arch:SSE2` instead of `/arch:IA32` to enable `clang-cl` to find the
SSE2 types. However, cargo's `cc` currently is still on 1.2.13.

To fix this for rust-lang/rust CI, we need to bump anything that
transitively relies on `cc` and tries to use `clang-cl` on `x86` Windows
targets to compile any C/C++ code that transitively use functions or
types that require SSE2 types, such as `<wchar.h>`.

### How should we test and review this PR?

The fix was initially intended for `rustc_{codegen_ssa,llvm}` `cc`, and
based on testing in rust-lang/rust#137724, I was
able to successfully build `rustc_{codegen_ssa,llvm}` with a forked `cc`
based on 1.2.15 which contains the fix from
rust-lang/cc-rs#1425. Note that in the same PR,
while the compiler build succeeded, the build of cargo itself failed
since it transitively used a `cc` *without* the fix to build
`curl-sys`[^dep-chain], which failed as one might expect (`curl-sys`
tries to build C code that uses `<wchar.h>` which runs into the same
problem). Hence, this PR is opened to bump cargo's `cc` to a `cc`
version containing the fix.

### Additional information

This `x86` Windows CI problem is:

- Discussed in
https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/spurious.20.28.3F.29.20i686.20msvc.20errors.
- Tracked by rust-lang/rust#137733.

#### `cc` changelog between 1.2.13 and 1.2.16

<details>
<summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary>

#####
[1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16)
- 2025-02-28

###### Fixed

- force windows compiler to run in `out_dir` to prevent artifacts in cwd
(#1415)

###### Other

- use `/arch:SSE2` for `x86` target arch (#1425)
- Regenerate windows-sys binding
([#1422](rust-lang/cc-rs#1422))
- Regenerate target info
([#1418](rust-lang/cc-rs#1418))
- Add LIB var when compiling flag_check (#1417)
- Change flag ordering
([#1403](rust-lang/cc-rs#1403))
- Fix archiver detection for musl cross compilation
([#1404](rust-lang/cc-rs#1404))

#####
[1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15)
- 2025-02-21

###### Other

- Regenerate target info
([#1406](rust-lang/cc-rs#1406))
- Always read from all `CFLAGS`-style flags
([#1401](rust-lang/cc-rs#1401))
- Simplify the error output on failed `Command` invocation
([#1397](rust-lang/cc-rs#1397))

#####
[1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14)
- 2025-02-14

###### Other

- Regenerate target info
([#1398](rust-lang/cc-rs#1398))
- Add support for setting `-gdwarf-{version}` based on RUSTFLAGS
([#1395](rust-lang/cc-rs#1395))
- Add support for alternative network stack io-sock on QNX 7.1 aarch64
and x86_64 ([#1312](rust-lang/cc-rs#1312))

</details>

[^dep-chain]: I think the dep chain is something like git2 ->
libgit2-sys -> curl -> curl-sys?
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.

Unable to get packages from source
4 participants