Matthias Krüger [Wed, 5 Jan 2022 14:05:48 +0000 (15:05 +0100)]
Rollup merge of #92574 - luojia65:riscv-kernel-dev-rust, r=Amanieu
Add RISC-V detection macro and more architecture instructions
This pull request includes:
- Update `stdarch` dependency to include ratified RISC-V supervisor and hypervisor instruction intrinsics which is useful in Rust kernel development
- Add macro `is_riscv_feature_detected!`
- Modify impl of `core::hint::spin_loop` to comply with latest version of `core::arch`
After this update, users may now develop RISC-V kernels and user applications more freely.
Matthias Krüger [Wed, 5 Jan 2022 14:05:44 +0000 (15:05 +0100)]
Rollup merge of #92092 - saethlin:fix-sort-guards-sb, r=danielhenrymantilla
Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison
I tried to run https://github.com/rust-lang/miri-test-libstd on `alloc` with `-Zmiri-track-raw-pointers`, and got a failure on the test `slice::panic_safe`. The test failure has nothing to do with panic safety, it's from how the test tests for panic safety.
I minimized the test failure into this very silly program:
```rust
use std::cell::Cell;
use std::cmp::Ordering;
#[derive(Clone)]
struct Evil(Cell<usize>);
fn main() {
let mut input = vec![Evil(Cell::new(0)); 3];
// Hits the bug pattern via CopyOnDrop in core
input.sort_unstable_by(|a, _b| {
a.0.set(0);
Ordering::Less
});
// Hits the bug pattern via InsertionHole in alloc
input.sort_by(|_a, b| {
b.0.set(0);
Ordering::Less
});
}
```
To fix this, I'm just removing the mutability/uniqueness where it wasn't required.
bors [Wed, 5 Jan 2022 09:27:18 +0000 (09:27 +0000)]
Auto merge of #92103 - Kobzol:stable-hash-skip-zero-bytes, r=the8472
Do not hash leading zero bytes of i64 numbers in Sip128 hasher
I was poking into the stable hasher, trying to improve its performance by compressing the number of hashed bytes. First I was experimenting with LEB128, but it was painful to implement because of the many assumptions that the SipHasher makes, so I tried something simpler - just ignoring leading zero bytes. For example, if an 8-byte integer can fit into a 4-byte integer, I will just hash the four bytes.
I wonder if this could produce any hashing ambiguity. Originally I thought so, but then I struggled to find any counter-example where this could cause different values to have the same hash. I'd be glad for any examples that could be broken by this (there are some ways of mitigating it if that would be the case). It could happen if you had e.g. 2x `u8` vs 1x `u16` hashed after one another in two different runs, but that can also happen now, without this "trick". And with collections, it should be fine, because the length is included in their hash.
I gathered some statistics for common values used in the `clap` benchmark. I observed that especially `i64` often had very low values, so I started with that type, let's see what perf does on CI.
There are some tradeoffs that we can try:
1) What types to use this optimization for? `u64`, `u32`, `u16`? Locally it was a slight loss for `u64`, I noticed that its values are often quite large.
2) What byte sizes to check? E.g. we can only distinguish between `u64`/`u32` or `u64`/`u8` instead of `u64`/`u32`/`u16`/`u8` to reduce branching (with `i64` it seemed to be better to go all the way down to `u8` locally though).
(The macro was introduced because I expect that I will be trying out this "trick" for different types).
bors [Wed, 5 Jan 2022 03:03:17 +0000 (03:03 +0000)]
Auto merge of #92567 - ehuss:update-cargo, r=ehuss
Update cargo
10 commits in fcef61230c3b6213b6b0d233a36ba4ebd1649ec3..358e79fe56fe374649275ca7aebaafd57ade0e8d
2021-12-17 02:30:38 +0000 to 2022-01-04 18:39:45 +0000
- Make rmeta_required no longer depend on whether timing is enabled (rust-lang/cargo#10254)
- The first version of pull request template (rust-lang/cargo#10218)
- Stabilize the `strip` profile option, now that rustc has stable `-C strip` (rust-lang/cargo#10088)
- Update docs for windows ssh-agent. (rust-lang/cargo#10248)
- Fix typo: substract -> subtract (rust-lang/cargo#10244)
- timings: Fix tick mark alignment (rust-lang/cargo#10239)
- Remove unused lifetimes (rust-lang/cargo#10238)
- Make levenshtein distance case insensitive. (rust-lang/cargo#10224)
- [docs] Adds basic CI yaml for GitHub Actions (rust-lang/cargo#10212)
- Add function for parsing already-read manifest (rust-lang/cargo#10209)
bors [Tue, 4 Jan 2022 23:01:49 +0000 (23:01 +0000)]
Auto merge of #92560 - matthiaskrgr:rollup-jeli7ip, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #91587 (core::ops::unsize: improve docs for DispatchFromDyn)
- #91907 (Allow `_` as the length of array types and repeat expressions)
- #92515 (RustWrapper: adapt for an LLVM API change)
- #92516 (Do not use deprecated -Zsymbol-mangling-version in bootstrap)
- #92530 (Move `contains` method of Option and Result lower in docs)
- #92546 (Update books)
- #92551 (rename StackPopClean::None to Root)
Matthias Krüger [Tue, 4 Jan 2022 20:23:12 +0000 (21:23 +0100)]
Rollup merge of #92551 - RalfJung:stack-pop-cleanup, r=oli-obk
rename StackPopClean::None to Root
With https://github.com/rust-lang/rust/pull/90102, `StackPopClean::None` is now only used for the "root" frame of the stack, so adjust its name accordingly and add an assertion.
Matthias Krüger [Tue, 4 Jan 2022 20:23:11 +0000 (21:23 +0100)]
Rollup merge of #92546 - ehuss:update-books, r=ehuss
Update books
## reference
3 commits in 06f9e61931bcf58b91dfe6c924057e42ce273ee1..f8ba2f12df60ee19b96de24ae5b73af3de8a446b
2021-12-17 07:31:40 -0800 to 2022-01-03 11:02:08 -0800
- Switch the default edition for examples to 2021 (rust-lang/reference#1125)
- Clarify behavior of x87 FP registers in inline assembly (rust-lang/reference#1126)
- Add inline assembly to the reference (rust-lang/reference#1105)
## book
36 commits in 8a0bb3c96e71927b80fa2286d7a5a5f2547c6aa4..d3740fb7aad0ea4a80ae20f64dee3a8cfc0c5c3c
2021-12-22 20:54:27 -0500 to 2022-01-03 21:46:04 -0500
- Add a concrete example of an optional value. Fixes rust-lang/book#2848.
- match isn't really an operator. Fixes rust-lang/book#2859
- Edits to edits of chapter 6
- Make fixes recommended by shellcheck
- Use shellcheck
- SIGH fix all the typos that were missed while spellcheck was broken
- SIGH add all the words to the dictionary that were missed while spellcheck was broken
- Remove test_harness from the dictionary
- sigh, the xkcd sandwich one
- Install aspell in CI
- set -eu in all bash scripts
- typo: assignement -> assignment
- Fix quotes
- Snapshot of ch12 for nostarch
- Use 'static lifetime earlier because that's more correct. Fixes rust-lang/book#2864.
- Add does_not_compile annotation to intermediate steps that don't compile
- Sidestep who provides output streams. Fixes rust-lang/book#2933.
- Remove note about primitive obsession. Fixes rust-lang/book#2863.
- Remove sentence encouraging writing tests on your own. Fixes rust-lang/book#2223.
- Bump mdBook version to 0.4.14 in workflow main.yml
- Past tense make better sense
- Past tense makes better sense
- Update the edition in all the listings' Cargo.toml
- Update the book to either say 2021 edition or not talk about editions
- Remove most of the 2018 edition text from the title page. Fixes rust-lang/book#2852.
- Fix word wrapping
- Emphasize return type is mandatory
- fix title capitalization
- Further edits to mention of --include-ignored, propagate to src
- feat: mention `cargo test -- --include-ignored`
- wording: get rid of "to from"
- interchanged position of `binary` and `library`
- Fix wrong word typo
- Further edits in rust-analyzer text
- appendix-04 IDE integration: Replaced rls by rust-analyzer
- Update link to Italian translation. Connects to rust-lang/book#2484.
## rustc-dev-guide
3 commits in 9bf0028b557798ddd07a6f652e4d0c635d3d6620..875464457c4104686faf667f47848aa7b0f0a744
2021-12-20 21:53:57 +0900 to 2021-12-28 22:17:49 -0600
- Update link to moved section (rust-lang/rustc-dev-guide#1282)
- Fix link in contributing.md (rust-lang/rustc-dev-guide#1280)
- Streamline "Getting Started" (rust-lang/rustc-dev-guide#1279)
Matthias Krüger [Tue, 4 Jan 2022 20:23:10 +0000 (21:23 +0100)]
Rollup merge of #92530 - dtolnay:contains, r=yaahc
Move `contains` method of Option and Result lower in docs
Follow-up to #92444 trying to get the `Option` and `Result` rustdocs in better shape.
This addresses the request in https://github.com/rust-lang/rust/issues/62358#issuecomment-645676285. The `contains` methods are previously too high up in the docs on both `Option` and `Result` — stuff like `ok` and `map` and `and_then` should all be featured higher than `contains`. All of those are more ubiquitously useful than `contains`.
Matthias Krüger [Tue, 4 Jan 2022 20:23:09 +0000 (21:23 +0100)]
Rollup merge of #92516 - Kobzol:bootstrap-symbol-mangling, r=Mark-Simulacrum
Do not use deprecated -Zsymbol-mangling-version in bootstrap
`-Zsymbol-mangling-version` now produces warnings unconditionally. So if you want to use legacy mangling for the compiler (`new-symbol-mangling = false` in `config.toml`), the build is now littered with warnings.
However, with this change, stage 1 `std` doesn't compile:
```
error: `-C symbol-mangling-version=legacy` requires `-Z unstable-options`
```
Even after the bootstrap compiler is updated and it will support `-Csymbol-mangling-version`, the bootstrap code would either need to use `-Z` for the legacy mangling or use `-C` in combination with `-Z unstable-options` (because `-C` + legacy is not allowed without the unstable options). Should we just add `-Z unstable-options` to `std` compilation to resolve this?
Btw I use legacy mangling because the new mangling is not supported by [Hotspot](https://github.com/KDAB/hotspot).
Matthias Krüger [Tue, 4 Jan 2022 20:23:08 +0000 (21:23 +0100)]
Rollup merge of #92515 - krasimirgg:rust-head-llvm-0301, r=nagisa
RustWrapper: adapt for an LLVM API change
No functional changes intended.
The LLVM commit https://github.com/llvm/llvm-project/commit/ec501f15a8b8ace2b283732740d6d65d40d82e09 removed the signed version of `createExpression`.
This adapts the Rust LLVM wrappers accordingly.
bors [Tue, 4 Jan 2022 19:56:13 +0000 (19:56 +0000)]
Auto merge of #92556 - matthiaskrgr:rollup-s9vopuj, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #91754 (Modifications to `std::io::Stdin` on Windows so that there is no longer a 4-byte buffer minimum in read().)
- #91884 (Constify `Box<T, A>` methods)
- #92107 (Actually set IMAGE_SCN_LNK_REMOVE for .rmeta)
- #92456 (Make the documentation of builtin macro attributes accessible)
- #92507 (Suggest single quotes when char expected, str provided)
- #92525 (intra-doc: Make `Receiver::into_iter` into a clickable link)
- #92532 (revert #92254 "Bump gsgdt to 0.1.3")
Matthias Krüger [Tue, 4 Jan 2022 15:34:20 +0000 (16:34 +0100)]
Rollup merge of #92532 - krasimirgg:gsgdt-down, r=Mark-Simulacrum
revert #92254 "Bump gsgdt to 0.1.3"
This reverts https://github.com/rust-lang/rust/pull/92254 since gsgdt 0.1.3 was yanked: https://github.com/rust-lang/rust/pull/92254#issuecomment-1004269481
Matthias Krüger [Tue, 4 Jan 2022 15:34:19 +0000 (16:34 +0100)]
Rollup merge of #92525 - zohnannor:patch-1, r=camelid
intra-doc: Make `Receiver::into_iter` into a clickable link
The documentation on `std::sync::mpsc::Iter` and `std::sync::mpsc::TryIter` provides links to the corresponding `Receiver` methods, unlike `std::sync::mpsc::IntoIter` does.
Matthias Krüger [Tue, 4 Jan 2022 15:34:16 +0000 (16:34 +0100)]
Rollup merge of #92456 - danielhenrymantilla:patch-1, r=petrochenkov
Make the documentation of builtin macro attributes accessible
`use ::std::prelude::v1::derive;` compiles on stable, so, AFAIK, there is no reason to have it be `#[doc(hidden)]`.
- What it currently looks like for things such as `#[test]`, `#[derive]`, `#[global_allocator]`: https://doc.rust-lang.org/1.57.0/core/prelude/v1/index.html#:~:text=Experimental-,pub,-use%20crate%3A%3Amacros%3A%3Abuiltin%3A%3Aglobal_allocator
<img width="767" alt="Screen Shot 2021-12-31 at 17 49 46" src="https://user-images.githubusercontent.com/9920355/147832999-cbd747a6-4607-4df6-8e57-c1675dcbc1c3.png">
and in `::std` they're just straight `hidden`.
<img width="452" alt="Screen Shot 2021-12-31 at 17 53 18" src="https://user-images.githubusercontent.com/9920355/147833105-c5ff8cd1-9e4d-4d2b-9621-b36aa3cfcb28.png">
- Here is how it looks like with this PR (assuming the `Rustc{De,En}codable` ones are not reverted):
<img width="778" alt="Screen Shot 2021-12-31 at 17 50 55" src="https://user-images.githubusercontent.com/9920355/147833034-84286342-dbf7-4e6e-9062-f39cd6c286a4.png">
<img width="291" alt="Screen Shot 2021-12-31 at 17 52 54" src="https://user-images.githubusercontent.com/9920355/147833109-c92ed55c-51c6-40a2-9205-f834d1e349c0.png">
Since this involves doc people to chime in, and since `jyn` is on vacation, I'll cc `@GuillaumeGomez` and tag the `rustdoc` team as well
Matthias Krüger [Tue, 4 Jan 2022 15:34:15 +0000 (16:34 +0100)]
Rollup merge of #92107 - nikic:rmeta-lnk-remove, r=nagisa
Actually set IMAGE_SCN_LNK_REMOVE for .rmeta
The code intended to set the IMAGE_SCN_LNK_REMOVE flag for the
.rmeta section, however the value of this flag was set to zero.
Instead use the actual value provided by the object crate.
This dates back to the original introduction of this code in
PR #84449, so we were never setting this flag. As I'm not on
Windows, I'm not sure whether that means we were embedding .rmeta
into executables, or whether the section ended up getting stripped
for some other reason.
Matthias Krüger [Tue, 4 Jan 2022 15:34:14 +0000 (16:34 +0100)]
Rollup merge of #91754 - Patrick-Poitras:rm-4byte-minimum-stdio-windows, r=Mark-Simulacrum
Modifications to `std::io::Stdin` on Windows so that there is no longer a 4-byte buffer minimum in read().
This is an attempted fix of issue #91722, where a too-small buffer was passed to the read function of stdio on Windows. This caused an error to be returned when `read_to_end` or `read_to_string` were called. Both delegate to `std::io::default_read_to_end`, which creates a buffer that is of length >0, and forwards it to `std::io::Stdin::read()`. The latter method returns an error if the length of the buffer is less than 4, as there might not be enough space to allocate a UTF-16 character. This creates a problem when the buffer length is in `0 < N < 4`, causing the bug.
The current modification creates an internal buffer, much like the one used for the write functions
I'd also like to acknowledge the help of ``@agausmann`` and ``@hkratz`` in detecting and isolating the bug, and for suggestions that made the fix possible.
Couple disclaimers:
- Firstly, I didn't know where to put code to replicate the bug found in the issue. It would probably be wise to add that case to the testing suite, but I'm afraid that I don't know _where_ that test should be added.
- Secondly, the code is fairly fundamental to IO operations, so my fears are that this may cause some undesired side effects ~or performance loss in benchmarks.~ The testing suite runs on my computer, and it does fix the issue noted in #91722.
- Thirdly, I left the "surrogate" field in the Stdin struct, but from a cursory glance, it seems to be serving the same purpose for other functions. Perhaps merging the two would be appropriate.
Finally, this is my first pull request to the rust language, and as such some things may be weird/unidiomatic/plain out bad. If there are any obvious improvements I could do to the code, or any other suggestions, I would appreciate them.
bors [Tue, 4 Jan 2022 00:25:23 +0000 (00:25 +0000)]
Auto merge of #92259 - Aaron1011:normal-mod-hashing, r=michaelwoerister
Remove special-cased stable hashing for HIR module
All other 'containers' (e.g. `impl` blocks) hashed their contents
in the normal, order-dependent way. However, `Mod` was hashing
its contents in a (sort-of) order-independent way. However, the
exact order is exposed to consumers through `Mod.item_ids`,
and through query results like `hir_module_items`. Therefore,
stable hashing needs to take the order of items into account,
to avoid fingerprint ICEs.
Unforuntately, I was unable to directly build a reproducer
for the ICE, due to the behavior of `Fingerprint::combine_commutative`.
This operation swaps the upper and lower `u64` when constructing the
result, which makes the function non-associative. Since we start
the hashing of module items by combining `Fingerprint::ZERO` with
the first item, it's difficult to actually build an example where
changing the order of module items leaves the final hash unchanged.
However, this appears to have been hit in practice in #92218
While we're not able to reproduce it, the fact that proc-macros
are involved (which can give an entire module the same span, preventing
any span-related invalidations) makes me confident that the root
cause of that issue is our method of hashing module items.
This PR removes all of the special handling for `Mod`, instead deriving
a `HashStable` implementation. This makes `Mod` consistent with other
'contains' like `Impl`, which hash their contents through the typical
derive of `HashStable`.
zohnannor [Mon, 3 Jan 2022 17:17:57 +0000 (20:17 +0300)]
Make `Receiver::into_iter` into a clickable link
The documentation on `std::sync::mpsc::Iter` and `std::sync::mpsc::TryIter` provides links to the corresponding `Receiver` methods, unlike `std::sync::mpsc::IntoIter` does.
bors [Mon, 3 Jan 2022 14:30:36 +0000 (14:30 +0000)]
Auto merge of #92518 - matthiaskrgr:rollup-fl8z4e7, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #90102 (Remove `NullOp::Box`)
- #92011 (Use field span in `rustc_macros` when emitting decode call)
- #92402 (Suggest while let x = y when encountering while x = y)
- #92409 (Couple of libtest cleanups)
- #92418 (Fix spacing in pretty printed PatKind::Struct with no fields)
- #92444 (Consolidate Result's and Option's methods into fewer impl blocks)
Failed merges:
- #92483 (Stabilize `result_cloned` and `result_copied`)
Matthias Krüger [Mon, 3 Jan 2022 13:44:21 +0000 (14:44 +0100)]
Rollup merge of #92444 - dtolnay:coremethods, r=joshtriplett
Consolidate Result's and Option's methods into fewer impl blocks
`Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds, with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods, like `unwrap_or` and `unwrap_or_default`, end up disproportionately far apart in source code and rustdocs:
I'd prefer for method to be in as few impl blocks as possible, with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead:
pub fn unwrap_or_default(self) -> T
where
T: Default,
{
...
}
}
```
*Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*
Matthias Krüger [Mon, 3 Jan 2022 13:44:16 +0000 (14:44 +0100)]
Rollup merge of #92011 - Aaron1011:decode-span, r=michaelwoerister
Use field span in `rustc_macros` when emitting decode call
This will cause backtraces to point to the location of
the field in the struct/enum, rather than the derive macro.
This makes it clear which field was being decoded when the
backtrace was captured (which is especially useful if
there are multiple fields with the same type).
Matthias Krüger [Mon, 3 Jan 2022 13:44:15 +0000 (14:44 +0100)]
Rollup merge of #90102 - nbdd0121:box3, r=jonas-schievink
Remove `NullOp::Box`
Follow up of #89030 and MCP rust-lang/compiler-team#460.
~1 month later nothing seems to be broken, apart from a small regression that #89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely.
bors [Mon, 3 Jan 2022 11:20:08 +0000 (11:20 +0000)]
Auto merge of #92179 - Aaron1011:incr-loaded-from-disk, r=michaelwoerister
Add `#[rustc_clean(loaded_from_disk)]` to assert loading of query result
Currently, you can use `#[rustc_clean]` to assert to that a particular
query (technically, a `DepNode`) is green or red. However, a green
`DepNode` does not mean that the query result was actually deserialized
from disk - we might have never re-run a query that needed the result.
Some incremental tests are written as regression tests for ICEs that
occured during query result decoding. Using
`#[rustc_clean(loaded_from_disk="typeck")]`, you can now assert
that the result of a particular query (e.g. `typeck`) was actually
loaded from disk, in addition to being green.
The LLVM commit
https://github.com/llvm/llvm-project/commit/ec501f15a8b8ace2b283732740d6d65d40d82e09
removed the signed version of `createExpression`. This adapts the Rust
LLVM wrappers accordingly.
bors [Mon, 3 Jan 2022 06:59:52 +0000 (06:59 +0000)]
Auto merge of #92080 - Aaron1011:pattern-ice, r=cjgillot
Move `PatKind::Lit` checking from ast_validation to ast lowering
Fixes #92074
This allows us to insert an `ExprKind::Err` when an invalid expression
is used in a literal pattern, preventing later stages of compilation
from seeing an unexpected literal pattern.
bors [Sun, 2 Jan 2022 15:49:23 +0000 (15:49 +0000)]
Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version, r=wesleywiser
Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0
This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options.
This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale, from #89917:
Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore, Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language, not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z, a-z, 0-9, and _.
Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers).
This pull request allows enabling the new v0 symbol-mangling-version.
See #89917 for references to the implementation of v0, and for references to the tool changes to decode Rust symbols.
bors [Sun, 2 Jan 2022 12:38:41 +0000 (12:38 +0000)]
Auto merge of #92066 - Smittyvb:concat_bytes-repeat, r=nagisa
Support [x; n] expressions in concat_bytes!
Currently trying to use `concat_bytes!` with a repeating array value like `[42; 5]` results in an error:
```
error: expected a byte literal
--> src/main.rs:3:27
|
3 | let x = concat_bytes!([3; 4]);
| ^^^^^^
|
= note: only byte literals (like `b"foo"`, `b's'`, and `[3, 4, 5]`) can be passed to `concat_bytes!()`
```
This makes it so repeating array syntax can be used the same way normal arrays can be. The RFC doesn't explicitly mention repeat expressions, but it seems reasonable to allow them as well, since normal arrays are allowed.
It is possible to make the compiler get stuck compiling forever with `concat_bytes!([3; 999999999])`, but I don't think that's much of an issue since you can do that already with `const X: [u8; 999999999] = [3; 999999999];`.
bors [Sun, 2 Jan 2022 06:28:34 +0000 (06:28 +0000)]
Auto merge of #92034 - petrochenkov:nolinknores, r=joshtriplett
Remove effect of `#[no_link]` attribute on name resolution
Previously it hid all non-macro names from other crates.
This has no relation to linking and can change name resolution behavior in some cases (e.g. glob conflicts), in addition to just producing the "unresolved name" errors.
I can kind of understand the possible reasoning behind the current behavior - if you can use names from a `no_link` crates then you can use, for example, functions too, but whether it will actually work or produce link-time errors will depend on random factors like inliner behavior.
(^^^ This is not the actual reason why the current behavior exist, I've looked through git history and it's mostly accidental.)
I think this risk is ok for such an obscure attribute, and we don't need to specifically prevent use of non-macro items from such crates.
(I'm not actually sure why would anyone use `#[no_link]` on a crate, even if it's macro only, if you aware of any use cases, please share. IIRC, at some point it was used for crates implementing custom derives - the now removed legacy ones, not the current proc macros.)
Extracted from https://github.com/rust-lang/rust/pull/91795.
bors [Sun, 2 Jan 2022 00:20:04 +0000 (00:20 +0000)]
Auto merge of #92482 - matthiaskrgr:rollup-uso1zi0, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #84083 (Clarify the guarantees that ThreadId does and doesn't make.)
- #91593 (Remove unnecessary bounds for some Hash{Map,Set} methods)
- #92297 (Reduce compile time of rustbuild)
- #92332 (Add test for where clause order)
- #92438 (Enforce formatting for rustc_codegen_cranelift)
- #92463 (Remove pronunciation guide from Vec<T>)
- #92468 (Emit an error for `--cfg=)`)
Matthias Krüger [Sat, 1 Jan 2022 21:49:53 +0000 (22:49 +0100)]
Rollup merge of #92468 - NieDzejkob:silent-cfg, r=petrochenkov
Emit an error for `--cfg=)`
Fixes #73026
See also: #64467, #89468
The issue stems from a `FatalError` being silently raised in
`panictry_buffer`. Normally this is not a problem, because
`panictry_buffer` emits the causes of the error, but they are not
themselves fatal, so they get filtered out by the silent emitter.
To fix this, we use a parser entrypoint which doesn't use
`panictry_buffer`, and we handle the error ourselves.
Matthias Krüger [Sat, 1 Jan 2022 21:49:52 +0000 (22:49 +0100)]
Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced, r=joshtriplett
Remove pronunciation guide from Vec<T>
I performed an extremely scientific poll on twitter, and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315
Matthias Krüger [Sat, 1 Jan 2022 21:49:48 +0000 (22:49 +0100)]
Rollup merge of #91593 - upsuper-forks:hashmap-set-methods-bound, r=dtolnay
Remove unnecessary bounds for some Hash{Map,Set} methods
This PR moves `HashMap::{into_keys,into_values,retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash, S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys,into_values}` on par with `HashMap::{keys,values,values_mut}` which are not bounded either.
Matthias Krüger [Sat, 1 Jan 2022 21:49:47 +0000 (22:49 +0100)]
Rollup merge of #84083 - ltratt:threadid_doc_tweak, r=dtolnay
Clarify the guarantees that ThreadId does and doesn't make.
The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee.
Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
bors [Sat, 1 Jan 2022 20:45:37 +0000 (20:45 +0000)]
Auto merge of #92396 - xfix:remove-commandenv-apply, r=Mark-Simulacrum
Remove CommandEnv::apply
It's not being used and uses unsound set_var and remove_var functions. This is an internal function that isn't exported (even with `process_internals` feature), so this shouldn't break anything.
Also see #92365. Note that this isn't the only use of those methods in standard library, so that particular pull request will need more changes than just this to work (in particular, `test_capture_env_at_spawn` is using `set_var` and `remove_var`).
Aaron Hill [Sat, 18 Dec 2021 17:23:49 +0000 (12:23 -0500)]
Move `PatKind::Lit` checking from ast_validation to ast lowering
Fixes #92074
This allows us to insert an `ExprKind::Err` when an invalid expression
is used in a literal pattern, preventing later stages of compilation
from seeing an unexpected literal pattern.
bjorn3 [Sun, 26 Dec 2021 14:35:50 +0000 (15:35 +0100)]
Make the rustc and rustdoc wrapper not depend on libbootstrap
This slightly improves compilation time by reducing linking time
(saving about a 1/10 of the the total compilation time after
changing rustbuild) and slightly reduces disk usage (from 16MB for
the rustc wrapper to 4MB).
bjorn3 [Sun, 26 Dec 2021 14:05:12 +0000 (15:05 +0100)]
Avoid the merge derive macro in rustbuild
The task of the macro is simple enough that a decl macro is almost ten
times shorter than the original proc macro. The proc macro is 159 lines
while the decl macro is just 18 lines.
This reduces the amount of dependencies of rustbuild from 45 to 37. It
also slight reduces compilation time from 47s to 44s for debug builds.
bors [Sat, 1 Jan 2022 13:28:13 +0000 (13:28 +0000)]
Auto merge of #92419 - erikdesjardins:coldland, r=nagisa
Mark drop calls in landing pads `cold` instead of `noinline`
Now that deferred inlining has been disabled in LLVM (#92110), this shouldn't cause catastrophic size blowup.
I confirmed that the test cases from https://github.com/rust-lang/rust/issues/41696#issuecomment-298696944 still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version)
r? `@nagisa`
cc `@arielb1` (this effectively reverts #42771 "mark calls in the unwind path as !noinline")
cc `@RalfJung` (fixes #46515)
bors [Sat, 1 Jan 2022 09:57:35 +0000 (09:57 +0000)]
Auto merge of #92471 - matthiaskrgr:rollup-lmduxwh, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #88310 (Lock bootstrap (x.py) build directory)
- #92097 (Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid)
- #92412 (Fix double space in pretty printed TryBlock)
- #92420 (Fix whitespace in pretty printed PatKind::Range)
- #92457 (Sync rustc_codegen_gcc)
- #92460 ([rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape)
- #92469 (Make tidy check for magic numbers that spell things)
Matthias Krüger [Sat, 1 Jan 2022 09:48:57 +0000 (10:48 +0100)]
Rollup merge of #92460 - dwrensha:fix-92267, r=petrochenkov
[rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape
Fixes #92267.
The problem was that the escape string "%%" does not need to appear at the very beginning of the format string, but
the iterator implementation assumed that it did.
The solution follows the pattern used by `format_foregin::shell::Subtitution::Escape`: https://github.com/rust-lang/rust/blob/8ed935e92dfb09ae388344b12284bf5110cf9265/compiler/rustc_builtin_macros/src/format_foreign.rs#L629
Matthias Krüger [Sat, 1 Jan 2022 09:48:54 +0000 (10:48 +0100)]
Rollup merge of #92097 - saethlin:split-without-deref, r=the8472
Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid
~I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that `as_mut_ptr_range` does.~ (Thanks `@RalfJung` for the guidance and clearing things up)
I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test `vec::test_extend_from_within`.
I minimized the test failure into this program:
```rust
#![feature(vec_split_at_spare)]
fn main() {
Vec::<i32>::with_capacity(1).split_at_spare_mut();
}
```
The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)
bors [Sat, 1 Jan 2022 05:21:22 +0000 (05:21 +0000)]
Auto merge of #92374 - ehuss:update-libssh2-sys, r=Mark-Simulacrum
Update libssh2-sys
Updates libssh2-sys from 0.2.19 to 0.2.23. This brings in libssh2 1.10 ([RELEASE-NOTES](https://github.com/libssh2/libssh2/blob/libssh2-1.10.0/RELEASE-NOTES)). One of the major changes is to add support for OpenSSH agent on Windows.
Jakub Kądziołka [Sat, 1 Jan 2022 04:12:56 +0000 (05:12 +0100)]
Emit an error for `--cfg=)`
Fixes #73026
See also: #64467, #89468
The issue stems from a `FatalError` being silently raised in
`panictry_buffer`. Normally this is not a problem, because
`panictry_buffer` emits the causes of the error, but they are not
themselves fatal, so they get filtered out by the silent emitter.
To fix this, we use a parser entrypoint which doesn't use
`panictry_buffer`, and we handle the error ourselves.
bors [Sat, 1 Jan 2022 02:03:23 +0000 (02:03 +0000)]
Auto merge of #92294 - Kobzol:rustdoc-meta-kind, r=GuillaumeGomez
Add Attribute::meta_kind
The `AttrItem::meta` function is being called on a lot of places, however almost always the caller is only interested in the `kind` of the result `MetaItem`. Before, the `path` had to be cloned in order to get the kind, now it does not have to be.
There is a larger related "problem". In a lot of places, something wants to know contents of attributes. This is accessed through `Attribute::meta_item_list`, which calls `AttrItem::meta` (now `AttrItem::meta_kind`), among other methods. When this function is called, the meta item list has to be recreated from scratch. Everytime something asks a simple question (like is this item/list of attributes `#[doc(hidden)]`?), the tokens of the attribute(s) are cloned, parsed and the results are allocated on the heap. That seems really unnecessary. What would be the best way to cache this? Turn `meta_item_list` into a query perhaps? Related PR: https://github.com/rust-lang/rust/pull/92227
bors [Fri, 31 Dec 2021 22:57:51 +0000 (22:57 +0000)]
Auto merge of #92465 - matthiaskrgr:rollup-yuary84, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #90383 (Extend check for UnsafeCell in consts to cover unions)
- #91375 (config.rs: Add support for a per-target default_linker option.)
- #91480 (rustdoc: use smaller number of colors to distinguish items)
- #92338 (Add try_reserve and try_reserve_exact for OsString)
- #92405 (Add a couple needs-asm-support headers to tests)
- #92435 (Sync rustc_codegen_cranelift)
- #92440 (Fix mobile toggles position)
Matthias Krüger [Fri, 31 Dec 2021 22:14:48 +0000 (23:14 +0100)]
Rollup merge of #92435 - bjorn3:sync_cg_clif-2021-12-30, r=bjorn3
Sync rustc_codegen_cranelift
The main highlight this sync is enforcing rustfmt and lack of warnings on cg_clif's CI. I will open a separate PR to remove the cg_clif exceptions for them from this repo.
projects / rust.git / log