bors [Sun, 28 Aug 2022 09:56:06 +0000 (09:56 +0000)]
Auto merge of #13133 - Veykril:diag-hack, r=Veykril
Move empty diagnostics workaround back into the server
This only touches on the diagnostics in one place instead of multiple as was previously done, since all published diagnostics will go through this code path anyways.
Matthias Krüger [Sun, 28 Aug 2022 07:35:17 +0000 (09:35 +0200)]
Rollup merge of #100955 - nrc:chain, r=joshtriplett
Some papercuts on error::Error
Renames the chain method, since I chain could mean anything and doesn't refer to a chain of sources (cc #58520) (and adds a comment explaining why sources is not a provided method on Error). Renames arguments to the request method from `req` to `demand` since the type is `Demand` rather than Request or Requisition.
Matthias Krüger [Sun, 28 Aug 2022 07:35:15 +0000 (09:35 +0200)]
Rollup merge of #100520 - jakubdabek:patch-1, r=thomcc
Add mention of `BufReader` in `Read::bytes` docs
There is a general paragraph about `BufRead` in the `Read` trait's docs, however using `bytes` without `BufRead` *always* has a large impact, due to reads of size 1.
Matthias Krüger [Sun, 28 Aug 2022 07:35:13 +0000 (09:35 +0200)]
Rollup merge of #99570 - XrXr:box-from-slice-docs, r=thomcc
Box::from(slice): Clarify that contents are copied
A colleague mentioned that they interpreted the old text
as saying that only the pointer and the length are copied.
Add a clause so it is more clear that the pointed to contents
are also copied.
Matthias Krüger [Sun, 28 Aug 2022 07:35:12 +0000 (09:35 +0200)]
Rollup merge of #98301 - ortem:pretty-printers-nonzero, r=wesleywiser
Add GDB/LLDB pretty-printers for NonZero types
Add GDB/LLDB pretty-printers for `NonZero` types.
These pretty-printers were originally implemented for IntelliJ Rust by ```@Kobzol``` in https://github.com/intellij-rust/intellij-rust/pull/5270.
Matthias Krüger [Sun, 28 Aug 2022 07:35:11 +0000 (09:35 +0200)]
Rollup merge of #97015 - nrc:read-buf-cursor, r=Mark-Simulacrum
std::io: migrate ReadBuf to BorrowBuf/BorrowCursor
This PR replaces `ReadBuf` (used by the `Read::read_buf` family of methods) with `BorrowBuf` and `BorrowCursor`.
The general idea is to split `ReadBuf` because its API is large and confusing. `BorrowBuf` represents a borrowed buffer which is mostly read-only and (other than for construction) deals only with filled vs unfilled segments. a `BorrowCursor` is a mostly write-only view of the unfilled part of a `BorrowBuf` which distinguishes between initialized and uninitialized segments. For `Read::read_buf`, the caller would create a `BorrowBuf`, then pass a `BorrowCursor` to `read_buf`.
In addition to the major API split, I've made the following smaller changes:
* Removed some methods entirely from the API (mostly the functionality can be replicated with two calls rather than a single one)
* Unified naming, e.g., by replacing initialized with init and assume_init with set_init
* Added an easy way to get the number of bytes written to a cursor (`written` method)
As well as simplifying the API (IMO), this approach has the following advantages:
* Since we pass the cursor by value, we remove the 'unsoundness footgun' where a malicious `read_buf` could swap out the `ReadBuf`.
* Since `read_buf` cannot write into the filled part of the buffer, we prevent the filled part shrinking or changing which could cause underflow for the caller or unexpected behaviour.
## Outline
```rust
pub struct BorrowBuf<'a>
impl Debug for BorrowBuf<'_>
impl<'a> From<&'a mut [u8]> for BorrowBuf<'a>
impl<'a> From<&'a mut [MaybeUninit<u8>]> for BorrowBuf<'a>
* ~~Migrate non-unix libs and tests~~
* ~~Naming~~
* ~~`BorrowBuf` or `BorrowedBuf` or `SliceBuf`? (We might want an owned equivalent for the async IO traits)~~
* ~~Should we rename the `readbuf` module? We might keep the name indicate it includes both the buf and cursor variations and someday the owned version too. Or we could change it. It is not publicly exposed, so it is not that important~~.
* ~~`read_buf` method: we read into the cursor now, so the `_buf` suffix is a bit weird.~~
* ~~Documentation~~
* Tests are incomplete (I adjusted existing tests, but did not add new ones).
cc https://github.com/rust-lang/rust/issues/78485, https://github.com/rust-lang/rust/issues/94741
supersedes: https://github.com/rust-lang/rust/pull/95770, https://github.com/rust-lang/rust/pull/93359
fixes #93305
bors [Sun, 28 Aug 2022 07:04:21 +0000 (07:04 +0000)]
Auto merge of #100863 - ehuss:sunset-rls, r=Mark-Simulacrum
Sunset RLS
This removes RLS per the plan outlined in https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html. This replaces the `rls` executable with a small program which will display an alert telling the user that RLS is no longer available.
An overview of the changes here:
* Removes the rls submodule and replaces it with a small stub program.
* `rls` is removed from `./x.py install`. I do not think users running `install` will need the stub.
* `rls` is removed from `./x.py test`, it doesn't have any tests.
Other things of note:
* I kept `DIST_REQUIRE_ALL_TOOLS` even though it is no longer needed, with the thought that it could be useful in the feature. However, I could remove it if desired.
* I kept `extra_deps` in `tool_extended` (which allows tools to depend on other things), even though it is no longer needed. This can also be removed if desired.
* ~~This keeps RLS in the macOS `pkg` installer and the Windows `msi` installer. I kinda lean towards removing it from those, but I'm not sure?~~ RLS has been removed from pkg and msi.
* This does not remove the analysis component. It is not clear if we should keep this or not. RLS was the primary user, but I think there are a few users that have made tools around it.
* There will be several followup steps after this PR:
* Updating the toolstate repo to remove RLS.
* Updating documentation, such as rustc-dev-guide, to remove references to RLS.
bors [Sun, 28 Aug 2022 04:16:29 +0000 (04:16 +0000)]
Auto merge of #92845 - Amanieu:std_personality, r=Mark-Simulacrum
Move EH personality functions to std
These were previously in the panic_unwind crate with dummy stubs in the
panic_abort crate. However it turns out that this is insufficient: we
still need a proper personality function even with -C panic=abort to
handle the following cases:
1) `extern "C-unwind"` still needs to catch foreign exceptions with -C
panic=abort to turn them into aborts. This requires landing pads and a
personality function.
2) ARM EHABI uses the personality function when creating backtraces.
The dummy personality function in panic_abort was causing backtrace
generation to get stuck in a loop since the personality function is
responsible for advancing the unwind state to the next frame.
// mod intrinsics
fn mask<T>(ptr: *const T, mask: usize) -> *const T
```
This is equivalent to `ptr.map_addr(|a| a & mask)` but also uses a cool llvm intrinsic.
Proposed in https://github.com/rust-lang/rust/pull/95643#issuecomment-1121562352
bors [Sat, 27 Aug 2022 16:57:19 +0000 (16:57 +0000)]
Auto merge of #100591 - est31:stabilization_placeholder, r=Mark-Simulacrum
Require stabilizations to use a placeholder instead of writing out stabilization version
Implements the idea from [this](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder) zulip stream.
It's a common phenomenon that feature stabilizations don't make it into a particular release, but the version is still inaccurate. Often this is caught in the PR, but it can also require subsequent changes to adjust/correct the version. A list with examples of such PRs is given in #100577, but it's far from complete.
This PR requires stabilization PRs to use the placeholder `CURRENT_RUSTC_VERSION`, enforced via tidy tooling. The PR also adds a tool that replaces the placeholder with the version number. It can be invoked via `./x.py run src/tools/replace-version-placeholder` and is supposed to be ran upon beta branching as well as version bumping and any backports to the beta branch. I filed PRs to the dev guide and forge to document these changes in the release and stabilization workflows:
* The [dev guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#determining-the-stabilization-version) PR: https://github.com/rust-lang/rustc-dev-guide/pull/1443
* The [std dev guide](https://std-dev-guide.rust-lang.org/) PR: https://github.com/rust-lang/std-dev-guide/pull/43
* The [forge](https://github.com/rust-lang/rust-forge) PR: https://github.com/rust-lang/rust-forge/pull/643
Nicholas Bishop [Sat, 27 Aug 2022 15:34:15 +0000 (11:34 -0400)]
Set DebuginfoKind::Pdb in msvc_base
This PDB setting was added to `windows_msvc_base` in
https://github.com/rust-lang/rust/pull/98051. It's also needed for the
UEFI targets, and since `uefi_msvc_base` and `windows_msvc_base` are the
only things that inherit from `msvc_base`, just move the PDB setting up
to `mscv_base` to cover both.
est31 [Mon, 15 Aug 2022 14:57:46 +0000 (16:57 +0200)]
tidy: forbid since values for features that point to the current release or future ones
It's a common phenomenon that feature stabilizations don't make it into
a particular release, but the version is still inaccurate. Often this
leads to subsequent changes to adjust/correct the version.
Instead, require people to put a placeholder that gets replaced during
beta branching time with the current rust version. That way, there is
no chance that an error can be introduced.
Usage of the placeholder is required on the nightly channel, and forbidden
on the stable and beta channels.
This selector was added in c7312fbae4979c6d4fdfbd1f55a71cd47d82a480. The bug can be seen at <https://doc.rust-lang.org/1.27.0/alloc/slice/trait.SliceIndex.html#foreign-impls>.
This rule was added to help with a `<table>` that was used for displaying the function signature [src] lockup. That lockup was changed in 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9 to use flexbox instead, leaving this selector unused (at least, for its original purpose).
Yuki Okushi [Sat, 27 Aug 2022 04:14:22 +0000 (13:14 +0900)]
Rollup merge of #101044 - notriddle:notriddle/css-hidden-by, r=jsha
rustdoc: remove unused CSS for `hidden-by-*-hider`
This CSS seems to have become obsolete with the move to `<details>` tags,
and its corresponding JavaScript was removed in aee054d05d8b795d35c0b448a4b731b6507aa459
Yuki Okushi [Sat, 27 Aug 2022 04:14:20 +0000 (13:14 +0900)]
Rollup merge of #100953 - joshtriplett:write-docs, r=Mark-Simulacrum
Update documentation for `write!` and `writeln!`
https://github.com/rust-lang/rust/pull/37472 added this documentation, but it
needs updating:
- Remove some documentation duplicated between `writeln!` and `write!`
- Update `write!` docs: can now import traits as `_` to avoid conflicts
- Expand example to show how to implement qualified trait names
Yuki Okushi [Sat, 27 Aug 2022 04:14:18 +0000 (13:14 +0900)]
Rollup merge of #100811 - czzrr:master, r=Mark-Simulacrum
Fix wrong compiletest filters on Windows
As discussed in [#79334](https://github.com/rust-lang/rust/issues/79334), when calling e.g.
```
python x.py test src/test/ui/expr/compound-assignment/eval-order.rs
```
on Windows, compiletest passes the filter `expr/compound-assignment/eval-order.rs` to libtest, which instead should be `expr\compound-assignment\eval-order.rs`, as that is the file found when collecting tests. This is what I fixed.
I'm not sure how to organize a test for this. Any suggestions?
Yuki Okushi [Sat, 27 Aug 2022 04:14:16 +0000 (13:14 +0900)]
Rollup merge of #99784 - est31:deny_cfg_attr_crate_type_name, r=Mark-Simulacrum
Make forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default
Turns the forward compatibility lint added by #83744 to deprecate `cfg_attr` usage with `#![crate_type]` and `#![crate_name]` attributes into deny by default. Copying the example from #83744:
```Rust
#![crate_type = "lib"] // remains working
#![cfg_attr(foo, crate_type = "bin")] // will stop working
```
Over 8 months have passed since #83744 was merged so I'd say this gives ample time for people to have been warned, so we can make the warning stronger. No usage was found via grep.app except for one, which was in an unmaintained code base that didn't seem to be used in the open source eco system. The crater run conducted in #83744 also didn't show up anything.
bors [Sat, 27 Aug 2022 03:19:12 +0000 (03:19 +0000)]
Auto merge of #100732 - dpaoliello:import_name_type, r=wesleywiser
Implementation of import_name_type
Fixes #96534 by implementing https://github.com/rust-lang/compiler-team/issues/525
Symbols that are exported or imported from a binary on 32bit x86 Windows can be named in four separate ways, corresponding to the [import name types](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type) from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (`STATUS_ENTRYPOINT_NOT_FOUND`) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's https://github.com/rust-lang/rust/issues/58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each `extern` function, and there is currently no way for users to provide this information.
This change adds a new `MetaNameValueStr` key to the `#[link]` attribute called `import_name_type`, and which accepts one of three values: `decorated`, `noprefix`, and `undecorated`.
A single DLL is likely to export all its functions using the same import type name, hence `import_name_type` is a parameter of `#[link]` rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.
Note: there is a fourth import name type defined in the PE-COFF spec, `IMPORT_ORDINAL`. This case is already handled by the `#[link_ordinal]` attribute. While it could be merged into `import_type_name`, that would not make sense as `#[link_ordinal]` provides per-function information (namely the ordinal itself).
Design decisions (these match the MCP linked above):
* For GNU, `decorated` matches the PE Spec and MSVC rather than the default behavior of `dlltool` (i.e., there will be a leading `_` for `stdcall`).
* If `import_name_type` is not present, we will keep our current behavior of matching the environment (MSVC vs GNU) default for decorating.
* Using `import_name_type` on architectures other than 32bit x86 will result in an error.
* Using `import_name_type` with link kinds other than `"raw-dylib"` will result in an error.
bors [Sat, 27 Aug 2022 00:38:06 +0000 (00:38 +0000)]
Auto merge of #101064 - compiler-errors:rollup-fwm5m5f, r=compiler-errors
Rollup of 9 pull requests
Successful merges:
- #100724 (Migrate ast lowering to session diagnostic)
- #100735 (Migrate `rustc_ty_utils` to `SessionDiagnostic`)
- #100738 (Diagnostics migr const eval)
- #100744 (Migrate rustc_mir_dataflow to diagnostic structs)
- #100776 (Migrate `rustc_lint` errors to `SessionDiagnostic`)
- #100817 (sugg: suggest the usage of boolean value when there is a typo in the keyword)
- #100836 (Migrate `rustc_attr` crate diagnostics)
- #100890 (Migrate rustc_driver to SessionDiagnostic)
- #100900 (on `region_errors.rs`)
Failed merges:
- #100831 (Migrate `symbol_mangling` module to new diagnostics structs)
Michael Goulet [Fri, 26 Aug 2022 22:56:29 +0000 (15:56 -0700)]
Rollup merge of #100890 - adriantombu:migrate_diagnostic_rustc_driver, r=davidtwco
Migrate rustc_driver to SessionDiagnostic
First timer noob here 👋🏽 I'm having a problem understanding how I can retrieve the span, and how to properly construct the error structs to avoid the current compilation errors.
Any help pointing me in the right direction would be much appreciated 🙌🏽
Michael Goulet [Fri, 26 Aug 2022 22:56:28 +0000 (15:56 -0700)]
Rollup merge of #100836 - hampuslidin:migrate-attr-crate-diagnostics, r=davidtwco
Migrate `rustc_attr` crate diagnostics
Hi!
This is my first PR to the rustc project, excited to be part of the development! This PR is part of the diagnostics effort, to make diagnostics translatable.
This adds a new suggestion when there is a well-known typo
With the following program
```rust
fn main() {
let x = True;
}
```
Now we have the following suggestion
```
error[E0425]: cannot find value `True` in this scope
--> test.rs:2:13
|
2 | let x = True;
| ^^^^ not found in this scope
|
help: you may want to use a bool value instead
|
2 | let x = true;
| ~~~~
Michael Goulet [Fri, 26 Aug 2022 22:56:25 +0000 (15:56 -0700)]
Rollup merge of #100776 - Rejyr:diagnostic-migration-rustc-lint, r=davidtwco
Migrate `rustc_lint` errors to `SessionDiagnostic`
Draft PR for migrating `rustc_lint` to `SessionDiagnostic`, as part of the [recent blog post](https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html)
Michael Goulet [Fri, 26 Aug 2022 22:56:22 +0000 (15:56 -0700)]
Rollup merge of #100735 - Facel3ss1:ty-utils-translation, r=davidtwco
Migrate `rustc_ty_utils` to `SessionDiagnostic`
I have migrated the `rustc_ty_utils` crate to use `SessionDiagnostic`, motivated by the [recent blog post about the diagnostic translation effort](https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html).
This is my first PR to the Rust repository, so if I have missed anything, or anything needs to be changed, please let me know! 😄
Michael Goulet [Fri, 26 Aug 2022 22:56:21 +0000 (15:56 -0700)]
Rollup merge of #100724 - JeanCASPAR:migrate-ast_lowering-to-session-diagnostic, r=davidtwco
Migrate ast lowering to session diagnostic
I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see https://github.com/rust-lang/rust/pull/100694).
bors [Fri, 26 Aug 2022 21:50:09 +0000 (21:50 +0000)]
Auto merge of #100043 - RalfJung:scalar-always-init, r=RalfJung
interpret: remove support for uninitialized scalars
With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely.
I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided.
Kevin Reid [Sat, 18 Jun 2022 21:28:47 +0000 (14:28 -0700)]
Add the syntax of references to their documentation summary.
Without this change, in <https://doc.rust-lang.org/1.63.0/std/#primitives>,
`reference` is the only entry in that list which does not contain the
syntax by which the type is named in source code. With this change, it
contains them, in roughly the same way as the `pointer` entry does.
bors [Fri, 26 Aug 2022 16:22:57 +0000 (16:22 +0000)]
Auto merge of #13087 - Veykril:config-update, r=Veykril
Remove auto-config patching from the VSCode client
This was introduced 4 months ago when we drastically changed the config keys. I'd like to remove this given I always felt uneasy doing edits to a users config from within r-a, and by now most if not all users should've swapped to a new enough version of r-a that should've updated their configs.
The extension will continue to work fine even with the outdated keys afterwards since we still do patching server side as well, and that one we'll have to support for quite some more time (if not until a proper 1.0 release where I assume we can allow ourselves some more user facing breakage)
(There also might've been a small bug in here that prevented users with certain outdated keys to prevent them from enabling certain keys for some reason)
This selector was added in c7312fbae4979c6d4fdfbd1f55a71cd47d82a480.
The bug can be seen at <https://doc.rust-lang.org/1.27.0/alloc/slice/trait.SliceIndex.html#foreign-impls>.
This rule was added to help with a `<table>` that was used for displaying the
function signature [src] lockup. That lockup was changed in 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9 to use flexbox instead, leaving this
selector unused (at least, for its original purpose).
bors [Fri, 26 Aug 2022 15:47:26 +0000 (15:47 +0000)]
Auto merge of #98051 - davidtwco:split-dwarf-stabilization, r=wesleywiser
session: stabilize split debuginfo on linux
Stabilize the `-Csplit-debuginfo` flag...
- ...on Linux for all values of the flag. Split DWARF has been implemented for a few months, hasn't had any bug reports and has had some promising benchmarking for incremental debug build performance.
- ..on other platforms for the default value. It doesn't make any sense that `-Csplit-debuginfo=packed` is unstable on Windows MSVC when that's the default behaviour, but keep the other values unstable.
Michael Howell [Fri, 26 Aug 2022 14:34:55 +0000 (07:34 -0700)]
rustdoc: remove unused CSS for `hidden-by-*-hider`
This CSS seems to have become obsolete with the move to `<details>` tags,
and its corresponding JavaScript was removed in aee054d05d8b795d35c0b448a4b731b6507aa459