Auto merge of #95621 - saethlin:remove-mpsc-transmute, r=RalfJung
Remove ptr-int transmute in std::sync::mpsc
Since https://github.com/rust-lang/rust/pull/95340 landed, Miri with `-Zmiri-check-number-validity` produces an error on the test suites of some crates which implement concurrency tools<sup>*</sup>, because it seems like such crates tend to use `std::sync::mpsc` in their tests. This fixes the problem by storing pointer bytes in a pointer.
<sup>*</sup> I have so far seen errors in the test suites of `once_cell`, `parking_lot`, and `crossbeam-utils`.
(just updating the list for fun, idk)
Also `threadpool`, `async-lock`, `futures-timer`, `fragile`, `scoped_threadpool`, `procfs`, `slog-async`, `scheduled-thread-pool`, `tokio-threadpool`, `mac`, `futures-cpupool`, `ntest`, `actix`, `zbus`, `jsonrpc-client-transports`, `fail`, `libp2p-gossipsub`, `parity-send-wrapper`, `async-broadcast,` `libp2p-relay`, `http-client`, `mockito`, `simple-mutex`, `surf`, `pollster`, and `pulse`. Then I turned the bot off.
Auto merge of #95502 - jyn514:doc-rustc, r=Mark-Simulacrum
Fix `x doc compiler/rustc`
This also has a few cleanups to `doc.rs`. The last two commits I don't care about, but the first commit I'd like to keep - it will be very useful for https://github.com/rust-lang/rust/issues/44293.
--- stderr
thread 'main' panicked at 'assertion failed: rustc.is_absolute()', src\bootstrap\build.rs:22:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
```
The problem was that the `dir.join` check only works with `rustc.exe`, not `rustc`.
Thanks `@Walther` for the help testing the fix!
Helps with https://github.com/rust-lang/rust/issues/94829.
Auto merge of #95435 - cjgillot:one-name, r=oli-obk
Make def names and HIR names consistent.
The name in the `DefKey` is interned to create the `DefId`, so it does not
require any query to access. This can be leveraged to avoid a few useless
HIR accesses for names.
~In order to achieve that, generic parameters created from universal
impl-trait are given the pretty-printed ast as a name, instead of
`{{opaque}}`.~
~Drive-by: the `TyCtxt::opt_item_name` used a dummy span for non-local
definitions. We have access to `def_ident_span`, so we use it.~
Rollup merge of #95831 - redzic:xor-uppercase, r=workingjubilee
Use bitwise XOR in to_ascii_uppercase
This saves an instruction compared to the previous approach, which
was to unset the fifth bit with bitwise OR.
Comparison of generated assembly on x86: https://godbolt.org/z/GdfvdGs39
This can also affect autovectorization, saving SIMD instructions as well: https://godbolt.org/z/cnPcz75T9
Not sure if `u8::to_ascii_lowercase` should also be changed, since using bitwise OR for that function does not require an extra bitwise negate since the code is setting a bit rather than unsetting a bit. `char::to_ascii_uppercase` already uses XOR, so no change seems to be required there.
It was used for deduplicating some errors for legacy code which are mostly deduplicated even without that, but at cost of global mutable state, which is not a good tradeoff.
cc https://github.com/rust-lang/rust/pull/95747#issuecomment-1091619403
r? ``@nnethercote``
Rollup merge of #95805 - c410-f3r:meta-vars, r=petrochenkov
Left overs of #95761
These are just nits. Feel free to close this PR if all modifications are not worth merging.
* `#![feature(decl_macro)]` is not needed anymore in `rustc_expand`
* `tuple_impls` does not require `$Tuple:ident`. I guess it is there to enhance readability?
Rollup merge of #95369 - jyn514:test-rustdoc, r=Mark-Simulacrum
Fix `x test src/librustdoc` with `download-rustc` enabled
The problem was two-fold:
- Bootstrap was hard-coding that unit tests should always run with stage1, not stage2, and
- It hard-coded the sysroot layout in stage1, which puts libLLVM.so in `lib/rustlib/` instead of just `lib/`.
This also takes the liberty of fixing `test src/librustdoc --no-doc`, which has been broken since it was first added. It would be nice at some point to unify this logic with other tests; I opened a Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Inconsistency.20in.20.60x.20test.60
Rollup merge of #95361 - scottmcm:valid-align, r=Mark-Simulacrum
Make non-power-of-two alignments a validity error in `Layout`
Inspired by the zulip conversation about how `Layout` should better enforce `size <= isize::MAX as usize`, this uses an N-variant enum on N-bit platforms to require at the validity level that the existing invariant of "must be a power of two" is upheld.
This was MIRI can catch it, and means there's a more-specific type for `Layout` to store than just `NonZeroUsize`.
It's left as `pub(crate)` here; a future PR could consider giving it a tracking issue for non-internal usage.
Rollup merge of #94794 - mlodato517:mlodato517-clarify-string-indexing-docs, r=Mark-Simulacrum
Clarify indexing into Strings
**This Commit**
Adds some clarity around indexing into Strings.
**Why?**
I was reading through the `Range` documentation and saw an
implementation for `SliceIndex<str>`. I was surprised to see this and
went to read the [`String`][0] documentation and, to me, it seemed to
say (at least) three things:
1. you cannot index into a `String`
2. indexing into a `String` could not be constant-time
3. indexing into a `String` does not have an obvious return type
I absolutely agree with the last point but the first two seemed
contradictory to the documentation around [`SliceIndex<str>`][1]
which mention:
1. you can do substring slicing (which is probably different than
"indexing" but, because the method is called `index` and I associate
anything with square brackets with "indexing" it was enough to
confuse me)
2. substring slicing is constant-time (this may be algorithmic ignorance
on my part but if `&s[i..i+1]` is O(1) then it seems confusing that
`&s[i]` _could not possibly_ be O(1))
So I was hoping to clarify a couple things and, hopefully, in this PR
review learn a little more about the nuances here that confused me in
the first place.
Mark Lodato [Thu, 10 Mar 2022 02:43:04 +0000 (21:43 -0500)]
Rework String UTF-8 Documentation
**This Commit**
Adds some clarity around indexing into Strings and the constraints
driving various decisions there.
**Why?**
The [`String` documentation][0] mentions how `String`s can't be indexed
but `Range` has an implementation for `SliceIndex<str>`. This can be
confusing. There are also several statements to explain the lack of
`String` indexing:
- the inability to index into a `String` is an implication of UTF-8
encoding
- indexing into a `String` could not be constant-time with UTF-8
encoding
- indexing into a `String` does not have an obvious return type
This last statement made sense but the first two seemed contradictory to
the documentation around [`SliceIndex<str>`][1] which mention:
- one can index into a `String` with a `Range` (also called substring
slicing but it uses the same syntax and the method name is `index`)
- `Range` indexing into a `String` is constant-time
To resolve this seeming contradiction the documentation is reworked to
more clearly explain what factors drive the decision to disallow
indexing into a `String` with a single number.
Auto merge of #95697 - klensy:no-strings, r=petrochenkov
refactor: simplify few string related interactions
Few small optimizations:
check_doc_keyword: don't alloc string for emptiness check
check_doc_alias_value: get argument as Symbol to prevent needless string convertions
check_doc_attrs: don't alloc vec, iterate over slice.
replace as_str() check with symbol check
get_single_str_from_tts: don't prealloc string
trivial string to str replace
LifetimeScopeForPath::NonElided use Vec<Symbol> instead of Vec<String>
AssertModuleSource use FxHashSet<Symbol> instead of BTreeSet<String>
CrateInfo.crate_name replace FxHashMap<CrateNum, String> with FxHashMap<CrateNum, Symbol>
It was used for deduplicating some errors for legacy code which are mostly deduplicated even without that, but at cost of global mutable state, which is not a good tradeoff.
Auto merge of #95840 - Dylan-DPC:rollup-erz5u6w, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #95308 (Reduce the amount of unstable features used in libproc_macro)
- #95676 (Update RLS)
- #95769 (Hide cross-crate `#[doc(hidden)]` associated items in trait impls)
- #95785 (interpret: err instead of ICE on size mismatches in to_bits_or_ptr_internal)
- #95802 (fix unused constant warning on some Windows targets)
- #95810 (Use `format-args-capture` and remove unnecessary nested blocks)
Rollup merge of #95785 - RalfJung:interpret-size-mismatch, r=oli-obk
interpret: err instead of ICE on size mismatches in to_bits_or_ptr_internal
We did this a while ago already for `to_i32()` and friends, but missed this one. That became quite annoying when I was debugging an ICE caused by `read_pointer` in a Miri shim where the code was passing an argument at the wrong type.
Having `scalar_to_ptr` be fallible is consistent with all the other `Scalar::to_*` methods being fallible. I added `unwrap` only in code outside the interpreter, which is no worse off than before now in terms of panics.
Auto merge of #95724 - Kobzol:ci-update-rustc-perf, r=nnethercote
CI: update `rustc-perf` version used in CI and also the corresponding PGO benchmarks
The old version was from May 2021. The `rustc-perf` benchmarks have seen a significant overhaul recently, so let's see if the new benchmarks can improve PGO performance.
Auto merge of #95835 - Dylan-DPC:rollup-l5mf2ad, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #90066 (Add new ThinBox type for 1 stack pointer wide heap allocated trait objects)
- #95374 (assert_uninit_valid: ensure we detect at least arrays of uninhabited types)
- #95599 (Strict provenance lints)
- #95751 (Don't report numeric inference ambiguity when we have previous errors)
- #95764 ([macro_metavar_expr] Add tests to ensure the feature requirement)
- #95787 (reword panic vs result section to remove recoverable vs unrecoverable framing)
- #95797 (Remove explicit delimiter token trees from `Delimited`.)
- #95804 (rustdoc: Fix empty doc comment with backline ICE)
Rollup merge of #95797 - nnethercote:rm-Delimited-all_tts, r=petrochenkov
Remove explicit delimiter token trees from `Delimited`.
They were introduced by the final commit in #95159 and gave a
performance win. But since the introduction of `MatcherLoc` they are no
longer needed. This commit reverts that change, making the code a bit
simpler.
Rollup merge of #95599 - niluxv:strict-provenance-lint, r=michaelwoerister
Strict provenance lints
See #95488.
This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts, as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API.
Based on an initial version of the lint by ```@Gankra``` in #95199.
Rollup merge of #95374 - RalfJung:assert_uninit_valid, r=Mark-Simulacrum
assert_uninit_valid: ensure we detect at least arrays of uninhabited types
We can't easily extend this check to *all* arrays (Cc https://github.com/rust-lang/rust/pull/87041), but it turns out the existing check already catches arrays of uninhabited types. So let's make sure it stays that way by adding them to the test.
Ben Kimock [Sun, 3 Apr 2022 19:50:11 +0000 (15:50 -0400)]
Remove ptr-int transmute in std::sync::mpsc
Since https://github.com/rust-lang/rust/pull/95340 landed, Miri with
-Zmiri-check-number-validity produces an error on the test suites of
some crates which implement concurrency tools, because it seems like
such crates tend to use std::sync::mpsc in their tests. This fixes the
problem by storing pointer bytes in a pointer.
Scott McMurray [Sun, 27 Mar 2022 07:06:26 +0000 (00:06 -0700)]
Make non-power-of-two alignments a validity error in `Layout`
Inspired by the zulip conversation about how `Layout` should better enforce `size < isize::MAX as usize`, this uses an N-variant enum on N-bit platforms to require at the validity level that the existing invariant of "must be a power of two" is upheld.
This was MIRI can catch it, and means there's a more-specific type for `Layout` to store than just `NonZeroUsize`.
Remove explicit delimiter token trees from `Delimited`.
They were introduced by the final commit in #95159 and gave a
performance win. But since the introduction of `MatcherLoc` they are no
longer needed. This commit reverts that change, making the code a bit
simpler.
Auto merge of #95519 - oli-obk:tait_ub2, r=compiler-errors
Enforce well formedness for type alias impl trait's hidden type
fixes #84657
This was not an issue with return-position-impl-trait because the generic bounds of the function are the same as those of the opaque type, and the hidden type must already be well formed within the function.
With type-alias-impl-trait the hidden type could be defined in a function that has *more* lifetime bounds than the type alias. This is fine, but the hidden type must still be well formed without those additional bounds.
Jane Lusby [Tue, 19 Oct 2021 22:23:19 +0000 (15:23 -0700)]
Add ThinBox type for 1 stack pointer sized heap allocated trait objects
Relevant commit messages from squashed history in order:
Add initial version of ThinBox
update test to actually capture failure
swap to middle ptr impl based on matthieu-m's design
Fix stack overflow in debug impl
The previous version would take a `&ThinBox<T>` and deref it once, which
resulted in a no-op and the same type, which it would then print causing
an endless recursion. I've switched to calling `deref` by name to let
method resolution handle deref the correct number of times.
I've also updated the Drop impl for good measure since it seemed like it
could be falling prey to the same bug, and I'll be adding some tests to
verify that the drop is happening correctly.
add test to verify drop is behaving
add doc examples and remove unnecessary Pointee bounds
ThinBox: use NonNull
ThinBox: tests for size
Apply suggestions from code review
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
use handle_alloc_error and fix drop signature
update niche and size tests
add cfg for allocating APIs
check null before calculating offset
add test for zst and trial usage
prevent optimizer induced ub in drop and cleanup metadata gathering
Split `fuzzy_provenance_casts` into lossy and fuzzy, feature gate and test it
* split `fuzzy_provenance_casts` into a ptr2int and a int2ptr lint
* feature gate both lints
* update documentation to be more realistic short term
* add tests for these lints
Rollup merge of #95705 - bstrie:x86nonetier, r=Mark-Simulacrum
Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts
This implements https://github.com/rust-lang/compiler-team/issues/499 , in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.
Rollup merge of #95634 - dtolnay:mailmap, r=Mark-Simulacrum
Mailmap update
I noticed there are a lot of contributors who appear multiple times in https://thanks.rust-lang.org/rust/all-time/, which makes their "rank" on that page inaccurate. For example Nick Cameron currently appears at rank 21 with 2010 contributions and at rank 27 with 1287 contributions, because some of those are from nrc⁠```@ncameron.org``` and some from ncameron⁠```@mozilla.com.``` In reality Nick's rank would be 11 if counted correctly, which is a large difference.
Solving this in a totally automated way is tricky because it involves figuring out whether Nick is 1 person with multiple emails, or is 2 people sharing the same name.
This PR addresses a subset of the cases: only where a person has committed under multiple names using the same email. This is still not something that can be totally automated (e.g. by modifying https://github.com/rust-lang/thanks to dedup by email instead of name+email) because:
- Some emails are not necessarily unique to one contributor, such as `ubuntu@localhost`.
- It involves some judgement and mindfulness in picking the "canonical name" among the names used with a particular email. This is the name that will appear on thanks.rust-lang.org. Humans change their names sometimes and can be sensitive or picky about the use of names that are no longer preferred.
For the purpose of this PR, I've tried to stick to the following heuristics which should be unobjectionable:
- If one of the names is currently set as the display name on the contributor's GitHub profile, prefer that name.
- If one of the names is used exclusively over the others in chronologically newer pull requests, prefer the newest name.
- If one of the names has whitespace and the other doesn't (i.e. is username-like), such as `Foo Bar` vs `FooBar` or `foobar` or `foo-bar123`, but otherwise closely resemble one another, then prefer the human-like name.
- If none of the above suffice in determining a canonical name and the contributor has some other name set on their GitHub profile, use the name from the GitHub profile.
- If no name on their GitHub profile but the profile links to their personal website which unambiguously identifies their preferred name, then use that name.
I'm also thinking about how to handle cases like Nick's, but that will be a project for a different PR. Basically I'd like to be able to find cases of the same person making commits that differ in name *and* email by looking at all the commits present in pull requests opened by the same GitHub user.
<details>
<summary>script</summary>
```toml
[dependencies]
anyhow = "1.0"
git2 = "0.14"
mailmap = "0.1"
```
```rust
use anyhow::{bail, Context, Result};
use git2::{Commit, Oid, Repository};
use mailmap::{Author, Mailmap};
use std::collections::{BTreeMap as Map, BTreeSet as Set};
use std::fmt::{self, Debug};
use std::fs;
use std::path::Path;
const REPO: &str = "/git/rust";
fn main() -> Result<()> {
let repo = Repository::open(REPO)?;
let head_oid = repo
.head()?
.target()
.context("expected head to be a direct reference")?;
let head = repo.find_commit(head_oid)?;
let mailmap_path = Path::new(REPO).join(".mailmap");
let mailmap_contents = fs::read_to_string(mailmap_path)?;
let mailmap = match Mailmap::from_string(mailmap_contents) {
Ok(mailmap) => mailmap,
Err(box_error) => bail!("{}", box_error),
};
let mut history = Set::new();
let mut merges = Vec::new();
let mut authors = Set::new();
let mut emails = Map::new();
let mut all_authors = Set::new();
traverse_left(head, &mut history, &mut merges, &mut authors, &mailmap)?;
while let Some((commit, i)) = merges.pop() {
let right = commit.parents().nth(i).unwrap();
authors.clear();
traverse_left(right, &mut history, &mut merges, &mut authors, &mailmap)?;
for author in &authors {
all_authors.insert(author.clone());
if !author.email.is_empty() {
emails
.entry(author.email.clone())
.or_insert_with(Map::new)
.entry(author.name.clone())
.or_insert_with(Set::new);
}
}
if let Some(summary) = commit.summary() {
if let Some(pr) = parse_summary(summary)? {
for author in &authors {
if !author.email.is_empty() {
emails
.get_mut(&author.email)
.unwrap()
.get_mut(&author.name)
.unwrap()
.insert(pr);
}
}
}
}
}
for (email, names) in emails {
if names.len() > 1 {
println!("<{}>", email);
for (name, prs) in names {
let prs = DebugSet(prs.iter().rev());
println!(" {} {:?}", name, prs);
}
}
}
Rollup merge of #95102 - compiler-errors:issue-94034-bug, r=jackh726
Add known-bug for #95034
Couldn't fix the issue, since I am no type theorist and inference variables in universes above U0 scare me. But I at least wanted to add a known-bug test for it.
Auto merge of #95775 - RalfJung:miri-windows-compat, r=ChrisDenton
make windows compat_fn (crudely) work on Miri
With https://github.com/rust-lang/rust/pull/95469, Windows `compat_fn!` now has to be supported by Miri to even make stdout work. Unfortunately, it relies on some outside-of-Rust linker hacks (`#[link_section = ".CRT$XCU"]`) that are rather hard to make work in Miri. So I came up with this crude hack to make this stuff work in Miri regardless. It should come at no cost for regular executions, so I hope this is okay.
Cc https://github.com/rust-lang/rust/issues/95627 `@ChrisDenton`
Auto merge of #95440 - jyn514:error-index, r=Mark-Simulacrum
Fix `x test src/tools/error_index_generator --stage {0,1}`
There were two fixes needed:
1. Use `top_stage` instead of `top_stage - 1`. There was a long and torturous comment about trying to match rustdoc's version, but it works better without the hard-coding than with (before it gave errors that `libtest.so` couldn't be found).
2. Make sure that `ci-llvm/lib` is added to LD_LIBRARY_PATH. Previously the error index would be unable to load LLVM for stage0 builds.
At some point we should probably have a discussion about how rustdoc stages should be numbered;
confusion between 0/1/2 has come up several times in bootstrap now. cc https://github.com/rust-lang/rust/issues/92538
Note that this is still broken when using `download-rustc = true` and `--stage 1`,
but that's *really* a corner case and should affect almost no one. `--stage {0,2}`
work fine with download-rustc.
Auto merge of #8657 - flip1995:raw_lint_desc, r=flip1995
Allow raw lint descriptions
update_lints now understands raw strings in declare_clippy_lint descriptions.
Supersedes #8655
cc `@Alexendoo` thanks for addressing this so quickly. I build a little bit simpler version of your patch. I don't think it really matters what `Literal` we're trying to tokenize, since we assume later, that it is some sort of `str`.
Auto merge of #95706 - petrochenkov:doclink4, r=GuillaumeGomez
rustdoc: Early doc link resolution fixes and refactorings
A subset of https://github.com/rust-lang/rust/pull/94857 that shouldn't cause perf regressions, but should fix some issues like https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/ICE.20in.20collect_intra_doc_links.2Ers https://github.com/rust-lang/rust/pull/95290 and improve performance in cases like https://github.com/rust-lang/rust/issues/95694.
Auto merge of #8635 - pbor:unsigned-abs, r=giraffate
Add a lint to detect cast to unsigned for abs() and suggest unsigned_…
…abs()
changelog: Add a [`cast_abs_to_unsigned`] that checks for uses of `abs()` that are cast to the corresponding unsigned integer type and suggest to replace them with `unsigned_abs()`.