The hack was added because upstream msys2 broke the ca-certificates
package, but since then it has been fixed. This reverts CI to use the
upstream package.
Rollup of 12 pull requests
Successful merges:
- #65405 (Create new error E0742 and add long error explanation)
- #65539 (resolve: Turn the "non-empty glob must import something" error into a lint)
- #65724 (ci: refactor pr tools job skipping)
- #65741 (Prevent help popup to disappear when clicking on it)
- #65832 (Re-enable Emscripten's exception handling support)
- #65843 (Enable dist for MIPS64 musl targets)
- #65898 (add basic HermitCore support within libtest)
- #65900 (proc_macro: clean up bridge::client::__run_expand{1,2} a bit.)
- #65906 (Update mdbook to 0.3.3)
- #65920 (Use rustc-workspace-hack for rustbook)
- #65930 (doc: use new feature gate for c_void type)
- #65936 (save-analysis: Account for async desugaring in async fn return types)
Failed merges:
- #65434 (Add long error explanation for E0577)
r? @ghost
save-analysis: Account for async desugaring in async fn return types
Closes#65590
When visiting the return type of an async function we need to take into account its desugaring, since it introduces a new definition under which the return type is redefined.
r? @nikomatsakis
Use rustc-workspace-hack for rustbook
As rustbook now depends transitively on openssl, it needs access to the
rustc-workspace-hack/all-static feature to pick up openssl-sys/vendored.
This fixes the rust build with `all-static = true` on systems where
openssl is not installed (e.g. when cross-compiling).
proc_macro: clean up bridge::client::__run_expand{1,2} a bit.
See commit titles/diffs for more details.
The first commit is made possible by #53451 being fixed (almost a year ago).
The last commit should remove the need for `#[allow(improper_ctypes)]` in #65134.
Re-enable Emscripten's exception handling support
Passes LLVM codegen and Emscripten link-time flags for exception
handling if and only if the panic strategy is `unwind`. Sets the
default panic strategy for Emscripten targets to `unwind`. Re-enables
tests that depend on unwinding support for Emscripten, including
`should_panic` tests.
r? @alexcrichton
ci: refactor pr tools job skipping
We have a job in our CI (PR's x86_64-gnu-tools) that's supposed to run only when a submodule is changed in the PR, and it works by having a task at the start of the build that skips all the following tasks if the condition isn't met.
Before this commit that task was gated with template parameters, which is a unique feature of Azure Pipelines. To make our CI more generic this commit switches the gate to use a simple environment variable plus a condition, which should be supported on more CI providers.
This PR also extracts the skipping logic into a script.
r? @alexcrichton
resolve: Turn the "non-empty glob must import something" error into a lint
This fixes#62334 by changing the error to a lint warning the glob. I changed the test but I'm very unsure of what I did as I do not know how to correctly check for the warning
submodules: update clippy from 66df92ae to c8e3cfbd
Changes:
````
travis: temporarily disable rustfmt ci check until #4742 is resolved
rustup https://github.com/rust-lang/rust/pull/65792/
Fix ICE #4579
Add regression test for ICE #4579
Run update_lints for Unicode lint
Re-add false positive check
Add raw string regression test for useless_format lint
Re-factor useless_format lint
Update Unicode lint tests
[Backported] Rustup to https://github.com/rust-lang/rust/pull/59545
````
Fixes#65888
r? @oli-obk @Manishearth
We have a job in our CI (PR's x86_64-gnu-tools) that's supposed to run
only when a submodule is changed in the PR, and it works by having a
task at the start of the build that skips all the following tasks if the
condition isn't met.
Before this commit that task was gated with template parameters, which
is a unique feature of Azure Pipelines. To make our CI more generic this
commit switches the gate to use a simple environment variable plus a
condition, which should be supported on more CI providers.
Fix#64153
This PR changes how the compiler detects if an object file from an upstream crate is a Rust object file or not. Instead of checking if the name starts with the crate name and ends with `.o` (which is not always the case, as described in #64153), it now just checks if the filename ends with `.rcgu.o`.
This fixes#64153. However, ideally we'd clean up the code around filename generation some more. Then this check could be made more robust.
r? @alexcrichton
Rollup of 5 pull requests
Successful merges:
- #65294 (Lint ignored `#[inline]` on function prototypes)
- #65318 (Call out the types that are non local on E0117)
- #65531 (Update backtrace to 0.3.40)
- #65562 (Improve the "try using a variant of the expected type" hint.)
- #65809 (Add new EFIAPI ABI)
Failed merges:
r? @ghost
As rustbook now depends transitively on openssl, it needs access to the
rustc-workspace-hack/all-static feature to pick up openssl-sys/vendored.
This fixes the rust build with `all-static = true` on systems where
openssl is not installed (e.g. when cross-compiling).
Add new EFIAPI ABI
Fixes#54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI.
Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
Improve the "try using a variant of the expected type" hint.
Fix https://github.com/rust-lang/rust/issues/65494.
- Change type-printing output.
- Use `span_to_snippet` when possible.
- Change the message to `try using a variant of the expected enum`
Lint ignored `#[inline]` on function prototypes
Fixes https://github.com/rust-lang/rust/issues/51280.
- Adds a `unused_attribute` lint for `#[inline]` on function prototypes.
- As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
Output previous stable error messaging when using stable build.
Fixes#65254
As I had mentioned previously there I have the logic running right now however I'm not getting the exact same syntax highlighting as there was originally for this error.
I'm currently getting the following:
```
error: expected expression, found statement (`let`)
--> src/main.rs:2:14
|
2 | let x = (let y = 6);
| ^^^^^^^^^
|
= note: variable declaration using `let` is a statement
```
I'd like to get the following instead:
```
| let x = (let y = 6);
| ^^^
```
My current understanding is that the `span` being passed into `lower_expr_let` is coming from `lowering.rs`. I still don't know how the byte range is calculated for the erroneous syntax and need to look into it a bit more. In the meantime does anybody have any hints/tips regarding this??
self-profiling: Record something more useful for crate metadata generation event.
Before this commit, we had an event that would only track the compression step
for proc-macros and Rust dylibs. After the commit we measure the time for
acutally generating the crate metadata bytes.
r? @wesleywiser
doc: introduce `once` in `iter::chain` document
I find it hard to find which one to use with `chain` when I only need to
chain one value. Also [`once`][1] talks about `chain`.
[1]: https://doc.rust-lang.org/nightly/std/iter/fn.once.html
suggest `const_in_array_repeat_expression` flag
This PR adds a suggestion to add the `#![feature(const_in_array_repeat_expression)]` attribute to the crate when a promotable expression is used in a repeat expression and the feature gate is not enabled.
Unfortunately, this ended up being a little bit more complex than I anticipated, which may not have been worth it given that this would all be removed when the feature is stabilized. However, with #65732 and #65737 being open, and the feature gate having not been being suggested to potential users, the feature might not be stabilized in a while, so maybe this is worth landing.
cc @Centril (addresses [this comment](https://github.com/rust-lang/rust/pull/61749#discussion_r307863857))
r? @ecstatic-morse (opened issues related to RFC 2203 recently)
rustc: use IndexVec<DefIndex, T> instead of Vec<T>.
Now that `DefIndex` is a proper index type, we can do that.
There was also an unnecessary `Option` I removed, I wonder if that has perf implications.
