Avoid BorrowMutError with RUSTC_LOG=debug
```console
$ touch empty.rs
$ env RUSTC_LOG=debug rustc +stage1 --crate-type=lib empty.rs
```
Fails with a `BorrowMutError` because source map files are already
borrowed while `features_query` attempts to format a log message
containing a span.
Release the borrow before the query to avoid the issue.
Simplify a nested bool match
Logically this first eliminates the innermost match by merging the patterns.
Then, in a second step, turns the newly innermost match into a `matches!` call.
Always record reference to binding in match if guards
When encountering a binding from a `match` pattern in its `if` guard when computing a generator's interior types, we must always record the type of a reference to the binding because of how `if` guards are lowered to MIR. This was missed in #75213 because the binding in that test case was autorefed and we recorded that adjusted type anyway.
Fixes#78366
[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path
This improves the performance of the `resolve_crate` function by 30% for
a very large single file crate with auto-generated C bindings.
cc `@rylev`
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:
```
llvm-wrapper/RustWrapper.cpp:939:31: required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
1301 | struct is_base_of
| ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
from llvm-wrapper/LLVMWrapper.h:1,
from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
| ^~~~~~~~~~~~~~~~~~
```
[reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124
A simple `unwrap` fixes the issue.
Update Clippy - temporary_cstring_as_ptr deprecation
In #75671 `clippy::temporary_cstr_as_ptr` was removed instead of being deprecated. This will trigger an error (unknown lint) for users that refer to that lint to e.g. allow it, instead of a more informative warning.
This update should fix that for nightly users.
r? @oli-obk
Prevent String::retain from creating non-utf8 strings when abusing panic
Fixes#78498
The idea is the same as `Vec::drain`, set the len to 0 so that nobody can observe the broken invariant if it escapes the function (in this case if `f` panics)
Update cargo
8 commits in dd83ae55c871d94f060524656abab62ec40b4c40..becb4c282b8f37469efb8f5beda45a5501f9d367
2020-10-20 19:31:26 +0000 to 2020-10-28 16:41:55 +0000
- List available packages if providing `--package` with an empty value (rust-lang/cargo#8808)
- Add a future-compatibility warning on allowed feature name characters. (rust-lang/cargo#8814)
- New namespaced features implementation. (rust-lang/cargo#8799)
- Remove redundant "For example, " (rust-lang/cargo#8810)
- Document platform-specific build-dependencies (rust-lang/cargo#8809)
- Remove some unused code. (rust-lang/cargo#8807)
- Some minor clippy fixes. (rust-lang/cargo#8804)
- Update TOML website links. (rust-lang/cargo#8803)
Use unwrapDIPtr because the Scope may be null.
I ran into an assertion when using debug information on Windows with LLVM assertions enabled.
It seems like we are using unwrap here (which in turn calls isa and requires the pointer to be non-null) but we expect the value to be null because that is what we are passing from rustc.
This change uses unwrapDIPtr which explicitly allows nullptr.
The FFI prototype for this method on the rust side has the `LLVMMetadataRef` parameter as `Scope: Option<&'a DIScope>`, and we always pass `None` when `msvc_like_names` is true.
rustc_span: improve bounds checks in byte_pos_to_line_and_col
The effect of this change is to consider edge-case spans that start or
end at the position one past the end of a file to be valid during span
hashing and encoding. This change means that these spans will be
preserved across incremental compilation sessions when they are part of
a serialized query result, instead of causing the dummy span to be used.
Dogfood {exclusive,half-open} ranges in compiler (nfc)
In particular, this allows us to write more explicit matches that
avoid the pitfalls of using a fully general fall-through case, yet
remain fairly ergonomic. Less logic is in guard cases, more is in
the actual exhaustive case analysis.
No functional changes.
Improve documentation for slice strip_* functions
Prompted by the stabilisation tracking issue #73413 I looked at the docs for `strip_prefix` and `strip_suffix` for both `str` and `slice`, and I felt they could be slightly improved.
Thanks for your attention.
ci: update x86_64-gnu and x86_64-gnu-debug to ubuntu:20.04
The former `ubuntu:19.10` reached EOL in July, 2020, whereas
`ubuntu:20.04` is an LTS release supported until 2025.
These are non-dist CI images, so the impact should be low.
Include non-rustup artifacts in the manifest
This PR fixes https://github.com/rust-lang/promote-release/issues/22 by including all the files we ship in the generated manifests, even the ones that are not installable through rustup. In practice this adds the following "artifacts":
* `source-code`: the tarball containing the full source code used to build the release (`rustc-{channel}-src.tar.xz`)
* `installer-msi`: the MSI installer for Windows systems (`rust-{channel}-{target}.msi`)
* `installer-pkg`: the PKG installer for macOS systems (`rust-{channel}-{target}.pkg`)
These files are included in a new `artifacts` table of the manifest, like so:
```toml
[[artifacts.installer-msi.target.aarch64-pc-windows-msvc]]
url = "https://example.com/2020-10-28/rust-nightly-aarch64-pc-windows-msvc.msi"
hash-sha256 = "6b41d5b829d20834c5d93628d008ec618f8914ee79303363bd13a86fd5f305dd"
[[artifacts.installer-msi.target.i686-pc-windows-gnu]]
url = "https://example.com/2020-10-28/rust-nightly-i686-pc-windows-gnu.msi"
hash-sha256 = "83f020de6e180c155add9fce1cea2ac6e5f744edbd6dc1581e24de8f56b2ca7a"
[[artifacts.installer-msi.target.i686-pc-windows-msvc]]
url = "https://example.com/2020-10-28/rust-nightly-i686-pc-windows-msvc.msi"
hash-sha256 = "dbc80c24e9d5df01616c6f216114b4351f51a94218e2368b5cebe4165b270702"
[[artifacts.installer-msi.target.x86_64-pc-windows-gnu]]
url = "https://example.com/2020-10-28/rust-nightly-x86_64-pc-windows-gnu.msi"
hash-sha256 = "8196eca3f02d72d4c8776ad4fcc72897125e2cf6404ae933e31c07e197e3c9fa"
[[artifacts.installer-msi.target.x86_64-pc-windows-msvc]]
url = "https://example.com/2020-10-28/rust-nightly-x86_64-pc-windows-msvc.msi"
hash-sha256 = "b2e7fd6463790732fcf9c726b9448068712341943199cb40fc11d1138b8a207b"
[[artifacts.installer-pkg.target.aarch64-apple-darwin]]
url = "https://example.com/2020-10-28/rust-nightly-aarch64-apple-darwin.pkg"
hash-sha256 = "70421c191752fb33886f8033b029e634bcc993b72308cef52a38405840e91f5c"
[[artifacts.installer-pkg.target.x86_64-apple-darwin]]
url = "https://example.com/2020-10-28/rust-nightly-x86_64-apple-darwin.pkg"
hash-sha256 = "ebd7a5acb61e82d85e855146cc9bd856f32228ee7f40dd94c659b00614ed4f1f"
[[artifacts.source-code.target."*"]]
url = "https://example.com/2020-10-28/rustc-nightly-src.tar.gz"
hash-sha256 = "5fcc487ee4c15c689de8ddf7daac7ff6a65c80498197b9aea58622dc2b3bca10"
[[artifacts.source-code.target."*"]]
url = "https://example.com/2020-10-28/rustc-nightly-src.tar.xz"
hash-sha256 = "0c618ef0ec5f64da1801e9d0df6c755f6ed1a8780ec5c8ee75e55614be51d42c"
```
Each artifact can be available for multiple targets, and each target can have multiple versions of the same file (for example, a `gz`-compressed one and a `xz`-compressed one). In the future rustup might add functionality to let users retrieve the artifacts, but that's not needed to land this PR, and whether to do the implementation is up to the rustup maintainers.
r? `@kinnison`
cc `@Mark-Simulacrum`
In particular, this allows us to write more explicit matches that
avoid the pitfalls of using a fully general fall-through case, yet
remain fairly ergonomic. Less logic is in guard cases, more is in
the actual exhaustive case analysis.
No functional changes.
