bors [Fri, 13 Nov 2020 20:06:46 +0000 (20:06 +0000)]
Auto merge of #78888 - richkadel:llvm-coverage-tests, r=tmandry
Fix and re-enable two coverage tests on MacOS
Note, in the coverage-reports test, the comment about MacOS was wrong.
The setting is based on config.toml llvm `optimize` setting. There
doesn't appear to be any environment variable I can check, and I
don't think we should add one. Testing the binary itself is a more
reliable way to check anyway.
For the coverage-spanview test, I removed the dependency on sed
altogether, which is much less ugly than trying to work around the
MacOS sed differences.
I tested these changes on Linux, Windows, and Mac.
bors [Fri, 13 Nov 2020 14:53:55 +0000 (14:53 +0000)]
Auto merge of #79017 - GuillaumeGomez:rollup-5orhudd, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #77151 (Add regression test for issue #76042)
- #77996 (Doc change: Remove mention of `fnv` in HashMap)
- #78463 (Add type to `ConstKind::Placeholder`)
- #78984 (Rustdoc check option)
- #78985 (add dropck test for const params)
- #78996 (add explicit test for const param promotion)
Guillaume Gomez [Fri, 13 Nov 2020 14:26:10 +0000 (15:26 +0100)]
Rollup merge of #77996 - tkaitchuck:master, r=m-ou-se
Doc change: Remove mention of `fnv` in HashMap
Disclaimer: I am the author of [aHash](https://github.com/tkaitchuck/aHash).
This changes the Rustdoc in `HashMap` from mentioning the `fnv` crate to mentioning the `aHash` crate, as an alternative `Hasher` implementation.
### Why
Fnv [has poor hash quality](https://github.com/rurban/smhasher), is [slow for larger keys](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), and does not provide dos resistance, because it is unkeyed (this can also cause [other problems](https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion)).
Fnv has acceptable performance for integers and has very poor performance with keys >32 bytes. This is the reason it was removed from the standard library in https://github.com/rust-lang/rust/pull/37229 .
Because regardless of which dimension you value, there are better alternatives, it does not make sense for anyone to consider using `fnv`.
The text mentioning `fnv` in the standard library continues to create confusion: https://github.com/rust-lang/hashbrown/issues/153 https://github.com/rust-lang/hashbrown/issues/9 . There are also a number of [crates using it](https://crates.io/crates/fnv/reverse_dependencies) a great many of which are hashing strings (Which is when Fnv is the [worst](https://github.com/cbreeden/fxhash#benchmarks), [possible](https://github.com/tkaitchuck/aHash#speed), [choice](http://cglab.ca/~abeinges/blah/hash-rs/).)
I think aHash makes the most sense to mention as an alternative because it is the most credible option (in my obviously biased opinion). It offers [good performance on numbers and strings](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), is [of high quality](https://github.com/tkaitchuck/aHash#hash-quality), and [provides dos resistance](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks). It is popular (see [stats](https://crates.io/crates/ahash)) and is the default hasher for [hashbrown](https://crates.io/crates/hashbrown) and [dashmap](https://crates.io/crates/dashmap) which are the most popular alternative hashmaps. Finally it does not have any of the [`gotcha` cases](https://github.com/tkaitchuck/aHash#fxhash) that `FxHash` suffers from. (Which is the other popular hashing option when DOS attacks are not a concern)
Signed-off-by: Tom Kaitchuck <tom.kaitchuck@emc.com>
bors [Fri, 13 Nov 2020 11:49:33 +0000 (11:49 +0000)]
Auto merge of #77990 - bugadani:copies, r=lcnr
Eliminate some temporary vectors
This PR changes `get_item_attrs` and `get_item_variances` to return iterator impls instead of vectors. On top of that, this PR replaces some seemingly unnecessary vectors with iterators or SmallVec, and also reserves space where we know (the minimum) number of elements that will be inserted. This change hopes to remove a few heap allocations and unnecessary copies.
bors [Fri, 13 Nov 2020 05:40:37 +0000 (05:40 +0000)]
Auto merge of #78826 - petrochenkov:mrscopes2, r=eddyb
resolve: Collapse `macro_rules` scope chains on the fly
Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports.
Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815
Mara Bos [Thu, 12 Nov 2020 18:46:17 +0000 (19:46 +0100)]
Rollup merge of #78972 - ehuss:update-cargo, r=ehuss
Update cargo
5 commits in d5556aeb8405b1fe696adb6e297ad7a1f2989b62..8662ab427a8d6ad8047811cc4d78dbd20dd07699
2020-11-04 22:20:36 +0000 to 2020-11-12 03:47:53 +0000
- Check if rust-src contains a vendor dir, and patch it in (rust-lang/cargo#8834)
- Improve performance of almost fresh builds (rust-lang/cargo#8837)
- Use u32/64::to/from_le_bytes instead of bit fiddling (rust-lang/cargo#8847)
- Avoid constructing an anyhow::Error when not necessary (rust-lang/cargo#8844)
- Skip extracting .cargo-ok files from packages (rust-lang/cargo#8835)
Mara Bos [Thu, 12 Nov 2020 18:46:14 +0000 (19:46 +0100)]
Rollup merge of #78950 - khyperia:spirv-asm, r=Amanieu
Add asm register information for SPIR-V
As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture), we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However, we cannot do so purely without frontend support: [this match](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_target/src/asm/mod.rs#L185) fails and so `asm!` is not supported ([error reported here](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_ast_lowering/src/expr.rs#L1095)). To resolve this, we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm), at which point the rust-gpu backend can do all the parsing and codegen that is needed.
This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. ``@Amanieu`` said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along.
I based this off the [wasm asm PR](https://github.com/rust-lang/rust/pull/78684), which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :(
---
Some open questions:
- What do we call the register class? Some context, SPIR-V is an SSA-based IR, there are "instructions" that create IDs (referred to as `<id>` in the spec), which can be referenced by other instructions. So, `reg` isn't exactly accurate, they're SSA IDs, not re-assignable registers.
- What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!`, but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents the `spirv` target from even reaching that codepath.
Mara Bos [Thu, 12 Nov 2020 18:46:11 +0000 (19:46 +0100)]
Rollup merge of #78857 - SkiFire13:bheap-opt, r=KodrAus
Improve BinaryHeap performance
By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child, i.e. `child == end - 1` is instead handled outside the loop, after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail.
I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM).
A quick benchmarks on my pc shows that the gains are pretty significant:
Mara Bos [Thu, 12 Nov 2020 18:46:09 +0000 (19:46 +0100)]
Rollup merge of #78836 - fanzier:struct-and-slice-destructuring, r=petrochenkov
Implement destructuring assignment for structs and slices
This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.
Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.
This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).
Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.
Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.
Joshua Nelson [Sun, 8 Nov 2020 16:45:13 +0000 (11:45 -0500)]
Don't reuse bindings for `ref mut`
Reusing bindings causes errors later in lowering:
```
error[E0596]: cannot borrow `vec` as mutable, as it is not declared as mutable
--> /checkout/src/test/ui/async-await/argument-patterns.rs:12:20
|
LL | async fn b(n: u32, ref mut vec: A) {
| ^^^^^^^^^^^
| |
| cannot borrow as mutable
| help: consider changing this to be mutable: `mut vec`
```
bors [Thu, 12 Nov 2020 15:34:09 +0000 (15:34 +0000)]
Auto merge of #76256 - tgnottingham:issue-74890, r=nikomatsakis
incr-comp: hash and serialize span end line/column
Hash both the length and the end location (line/column) of a span. If we
hash only the length, for example, then two otherwise equal spans with
different end locations will have the same hash. This can cause a
problem during incremental compilation wherein a previous result for a
query that depends on the end location of a span will be incorrectly
reused when the end location of the span it depends on has changed. A
similar analysis applies if some query depends specifically on the
length of the span, but we only hash the end location. So hash both.
I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.
Guillaume Gomez [Thu, 12 Nov 2020 10:31:51 +0000 (11:31 +0100)]
Rollup merge of #78960 - ethanboxx:const-gen-test-default-error, r=lcnr
Test default values for const parameters.
The last topic on #78433
I originally intended to place these tests in a single file, however, due to them being parser errors that are fatal, they must be in separate files to be detected.
Guillaume Gomez [Thu, 12 Nov 2020 10:31:47 +0000 (11:31 +0100)]
Rollup merge of #78921 - GuillaumeGomez:search-result-title, r=jyn514
Improve the page title switch handling between search and doc
The current behavior often "forgets" to update the page title when discarding/putting back the search results. This isn't optimal which is why I wrote this fix.
Guillaume Gomez [Thu, 12 Nov 2020 10:31:45 +0000 (11:31 +0100)]
Rollup merge of #78916 - lcnr:const-generics-tests, r=varkor
extend const generics test suite
should implement most of #78433, especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue.
bors [Thu, 12 Nov 2020 10:28:15 +0000 (10:28 +0000)]
Auto merge of #78773 - GuillaumeGomez:theme-picker-shortcut, r=jyn514
Add shortcut for theme picker menu
Follow-up of #78584
Just like you can focus the search input by pressing "S", you can now access the theme picker menu by pressing "T" and navigate through the options only using the keyboard.
Rich Kadel [Sun, 8 Nov 2020 19:06:05 +0000 (11:06 -0800)]
Fix and re-enable two coverage tests on MacOS
Note, in the coverage-reports test, the comment about MacOS was wrong.
The setting is based on config.toml llvm `optimize` setting. There
doesn't appear to be any environment variable I can check, and I
don't think we should add one. Testing the binary itself is a more
reliable way to check anyway.
For the coverage-spanview test, I removed the dependency on sed
altogether, which is much less ugly than trying to work around the
MacOS sed differences.
I tested these changes on Linux, Windows, and Mac.
bors [Thu, 12 Nov 2020 05:52:17 +0000 (05:52 +0000)]
Auto merge of #78965 - jryans:emscripten-threads-libc, r=kennytm
Update thread and futex APIs to work with Emscripten
This updates the thread and futex APIs in `std` to match the APIs exposed by
Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the
thread parker to compile without errors related to the missing `futex` module.
To make use of this, Rust code must be compiled with `-C target-feature=atomics`
and Emscripten must link with `-pthread`.
I have confirmed this works well locally when building multithreaded crates.
Attempting to enable `std` thread tests currently fails for seemingly obscure
reasons and Emscripten is currently disabled in CI, so further work is needed to
have proper test coverage here.
J. Ryan Stinnett [Wed, 11 Nov 2020 22:25:48 +0000 (22:25 +0000)]
Update thread and futex APIs to work with Emscripten
This updates the thread and futex APIs in `std` to match the APIs exposed by
Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the
thread parker to compile without errors related to the missing `futex` module.
To make use of this, Rust code must be compiled with `-C target-feature=atomics`
and Emscripten must link with `-pthread`.
I have confirmed this works well locally when building multithreaded crates.
Attempting to enable `std` thread tests currently fails for seemingly obscure
reasons and Emscripten is currently disabled in CI, so further work is needed to
have proper test coverage here.
bors [Thu, 12 Nov 2020 00:33:55 +0000 (00:33 +0000)]
Auto merge of #78782 - petrochenkov:nodoctok, r=Aaron1011
Do not collect tokens for doc comments
Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).
(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)
bors [Wed, 11 Nov 2020 22:20:07 +0000 (22:20 +0000)]
Auto merge of #78956 - jonas-schievink:rollup-r53giob, r=jonas-schievink
Rollup of 11 pull requests
Successful merges:
- #78216 (Duration::zero() -> Duration::ZERO)
- #78354 (Support enable/disable sanitizers/profiler per target)
- #78417 (BTreeMap: split off most code of append)
- #78832 (look at assoc ct, check the type of nodes)
- #78873 (Add flags customizing behaviour of MIR inlining)
- #78899 (Support inlining diverging function calls)
- #78923 (Cleanup and comment intra-doc link pass)
- #78929 (rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`)
- #78930 (rustc_taret: Remove `TargetOptions::is_like_android`)
- #78942 (Fix typo in comment)
- #78947 (Ship llvm-cov through llvm-tools)
Jonas Schievink [Wed, 11 Nov 2020 19:59:14 +0000 (20:59 +0100)]
Rollup merge of #78947 - dalance:llvm_cov, r=Mark-Simulacrum
Ship llvm-cov through llvm-tools
`llvm-cov` is used to generate coverage report with LLVM InstrProf-based code coverage #34701.
So if `llvm-cov` is shipped through llvm-tools, users can try it easily accorging to the instruction of [The Rust Unstable Book](https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html).
Jonas Schievink [Wed, 11 Nov 2020 19:59:09 +0000 (20:59 +0100)]
Rollup merge of #78929 - petrochenkov:linuxbase, r=joshtriplett
rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`
Follow up to https://github.com/rust-lang/rust/pull/77729.
Changes the target spec hierarchy for Linux from
```
linux_base
├── linux_musl_base
└── linux_uclibc_base
```
where `linux_base` is really `linux_gnu_base` and the inheriting targets replace target env "gnu" with "musl"/"uclibc" to
```
linux_base
├── linux_gnu_base
├── linux_musl_base
└── linux_uclibc_base
```
which is slightly less confusing (I think).
Jonas Schievink [Wed, 11 Nov 2020 19:59:05 +0000 (20:59 +0100)]
Rollup merge of #78899 - tmiasko:inline-diverging, r=oli-obk
Support inlining diverging function calls
The existing heuristic does penalize diverging calls to some degree, but since
it never inlined them previously it might need some further modifications.
Additionally introduce storage markers for all temporaries created by
the inliner. The temporary introduced for destination rebrorrow, didn't
use them previously.
Jonas Schievink [Wed, 11 Nov 2020 19:59:03 +0000 (20:59 +0100)]
Rollup merge of #78873 - tmiasko:inline-opts, r=oli-obk
Add flags customizing behaviour of MIR inlining
* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
functions with inline hint.
Having those as configurable flags makes it possible to experiment with with
different inlining thresholds and substantially increase test coverage of MIR
inlining when used with increased thresholds (for example, necessary to test
#78844).
Jonas Schievink [Wed, 11 Nov 2020 19:59:00 +0000 (20:59 +0100)]
Rollup merge of #78417 - ssomers:btree_chop_up_2, r=Mark-Simulacrum
BTreeMap: split off most code of append
To complete #78056, move the last single-purpose pieces of code out of map.rs into a separate module. Also, tweaked documentation and safeness - I doubt think this code would be safe if the iterators passed in wouldn't be as sorted as the method says they should be - and bounds on MergeIterInner.
Jonas Schievink [Wed, 11 Nov 2020 19:58:56 +0000 (20:58 +0100)]
Rollup merge of #78354 - 12101111:rustbuild_profiler, r=Mark-Simulacrum
Support enable/disable sanitizers/profiler per target
This PR add options under `[target.*]` of `config.toml` which can enable or disable sanitizers/profiler runtime for corresponding target.
If these options are empty, the global options under `[build]` will take effect.
Jonas Schievink [Wed, 11 Nov 2020 19:58:52 +0000 (20:58 +0100)]
Rollup merge of #78216 - workingjubilee:duration-zero, r=m-ou-se
Duration::zero() -> Duration::ZERO
In review for #72790, whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value, supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO, which would be reason enough.
ZERO also "makes sense" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method, especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const, which could hurt discoverability of the associated constants overall. Elsewhere in `std`, methods for obtaining a constant value were even deprecated, as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value).
Most importantly, ZERO costs less to use. A match supports a const pattern, but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise, while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value, "can" is not "will". Only const contexts have a strong promise of such. Even without that in mind, the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use, may cost less to optimize, and seems to have more of a community consensus for it, the associated const seems best.
bors [Wed, 11 Nov 2020 16:24:43 +0000 (16:24 +0000)]
Auto merge of #78790 - Gankra:rust-src-vendor, r=Mark-Simulacrum
Vendor libtest's dependencies in the rust-src component
This is the Rust side of https://github.com/rust-lang/wg-cargo-std-aware/issues/23
Note that this won't produce a useful result for `cargo -Zbuild-std` if there are multiple versions of a crate vendored, but will otherwise produce a valid vendor dir.
See https://github.com/rust-lang/cargo/pull/8834 for the other half of this change.
Nicholas-Baron [Fri, 6 Nov 2020 21:24:55 +0000 (13:24 -0800)]
Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.
A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.
The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
bors [Wed, 11 Nov 2020 01:18:18 +0000 (01:18 +0000)]
Auto merge of #78920 - jonas-schievink:rollup-w2mjsuh, r=jonas-schievink
Rollup of 14 pull requests
Successful merges:
- #76765 (Make it more clear what an about async fn's returns when referring to what it returns)
- #78574 (Use check-pass instead of build-pass in regions ui test suite)
- #78669 (Use check-pass instead of build-pass in some consts ui test suits)
- #78847 (Assert that a return place is not used for indexing during integration)
- #78854 (Workaround for "could not fully normalize" ICE )
- #78875 (rustc_target: Further cleanup use of target options)
- #78887 (Add comments to explain memory usage optimization)
- #78890 (comment attribution fix)
- #78896 (Clarified description of write! macro)
- #78897 (Add missing newline to error message of the default OOM hook)
- #78898 (add regression test for #78892)
- #78908 ((rustdoc) [src] link for types defined by macros shows invocation, not defintion)
- #78910 (Fix links to stabilized versions of some intrinsics)
- #78912 (Add macro test for min-const-generics)
Jonas Schievink [Tue, 10 Nov 2020 13:45:32 +0000 (14:45 +0100)]
Rollup merge of #78908 - liketechnik:fix_macro_expand_src_link, r=jyn514
(rustdoc) [src] link for types defined by macros shows invocation, not defintion
Previously the [src] link on types defined by a macro pointed to the macro definition.
This pr makes the Clean-Implementation for Spans aware of macro defined types, so that the link points to the invocation instead.
I'm not totally sure if it's okay to add the 'macro awareness' in the Clean-Implementation, because it erases that knowledge for all following code. Maybe it would be more sensible to add the check only for the link generation at https://github.com/rust-lang/rust/blob/25f6938da459a57b43bdf16ed6bdad3225b2a3ce/src/librustdoc/html/render/mod.rs#L1619
Jonas Schievink [Tue, 10 Nov 2020 13:45:28 +0000 (14:45 +0100)]
Rollup merge of #78897 - hyd-dev:alloc-error-hook-newline, r=m-ou-se
Add missing newline to error message of the default OOM hook
Currently the default OOM hook in libstd does not end the error message with a newline:
```
memory allocation of 4 bytes failedtimeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11: 7 Aborted timeout --signal=KILL ${timeout} "$`@"`
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=030d8223eb57dfe47ef157709aa26542
This is because the `fmt::Arguments` passed to `dumb_print()` does not end with a newline. All other calls to `dumb_print()` in libstd pass a `\n`-ended `fmt::Arguments` to `dumb_print()`. For example:
https://github.com/rust-lang/rust/blob/25f6938da459a57b43bdf16ed6bdad3225b2a3ce/library/std/src/sys_common/util.rs#L18
I think the `\n` was forgotten in #51264.
This PR appends `\n` to the error string.
~~Note that I didn't add a test, because I didn't find tests for functions in ` library/std/src/alloc.rs` or a test that is similar to the test of this change would be.~~ *Edit: CI told me there is an existing test. Sorry.*
projects / rust.git / log