| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #118187 (Recompile LLVM when it changes in the git sources)
- #118210 (intercrate ambiguity causes: ignore candidates which don't apply)
- #118215 (Add common trait for crate definitions)
- #118238 (memcpy assumptions: update GCC link)
- #118243 (EvalCtxt::commit_if_ok don't inherit nested goals)
- #118245 (Add `Span` to `TraitBoundModifier`)
- #118246 (Remove a hack for effects)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove a hack for effects
Fallback was implemented in #115727, which addresses the inference errors mentioned in the comments.
|
|
Add `Span` to `TraitBoundModifier`
This improves diagnostics for the message "`~const` is not allowed here", and also fixes the span that we use when desugaring `~const Tr` into `Tr<host>` in effects desugaring.
|
|
EvalCtxt::commit_if_ok don't inherit nested goals
we use it to check whether an alias is rigid, so we want to avoid considering an alias rigid simply because the inference constraints from normalizing it caused another nested goal fail
r? `@compiler-errors`
|
|
memcpy assumptions: update GCC link
GCC now has this documented on an official website, not just in the bugtracker.
|
|
Add common trait for crate definitions
In stable mir, we specialize DefId, however some functionality is the same for every definition, such as def paths, and getting their crate. Use a trait to implement those.
|
|
r=compiler-errors
intercrate ambiguity causes: ignore candidates which don't apply
r? `@compiler-errors`
|
|
Recompile LLVM when it changes in the git sources
Utilize a smart hash for 'llvm-finished-building' to enable recompilation of LLVM with each change in the git sources.
Each change generates a unique hash value in 'llvm-finished-building', which ensures LLVM compilations only triggered with further changes.
Resolves #111893
cc `@rust-lang/wg-llvm`
|
|
feat: make `let_binding_suggestion` more reasonable
This is my first PR for rustc, which trying to fix https://github.com/rust-lang/rust/issues/117894, I am not familiar with some internal api so maybe some modification here isn't the way to go, appreciated for any review suggestion.
|
|
|
|
|
|
|
|
Fix tidy tripping up on untracked files with special characters in their name
Previously, the tidy tool would fault if an untracked file had a space or other special characters in its name. If there was an untracked file "foo bar", it would include the quoting in it's path and split on the first space, giving output like this:
`skip untracked path "foo during rustfmt invocations`
|
|
Indicate that multiplication in Layout::array cannot overflow
Since https://github.com/rust-lang/rust/pull/113113, we have added a check that skips calling into the allocator at all if `capacity == 0`. The global, default allocator will not actually try to allocate though; it returns a dangling pointer explicitly. However, these two checks are not merged/deduplicated by LLVM and so we're comparing to zero twice whenever vectors are allocated/grown. Probably cheap, but also potentially expensive in code size and seems like an unfortunate miss.
This removes that extra check by telling LLVM that the multiplication as part of Layout::array can't overflow, turning the original non-zero value into a zero value afterwards. In my checks locally this successfully drops the duplicate comparisons.
See https://rust.godbolt.org/z/b6nPP9dcK for a code example.
```rust
pub fn foo(elements: usize) -> Vec<u32> {
Vec::with_capacity(elements)
}
```
r? `@scottmcm` since you touched this in a32305a80fd1409b054e97836321bd0621b142fd - curious if you have thoughts on doing this / can confirm my model of this being correct.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #116807 (Improve rewind documentation)
- #117656 (Update windows-bindgen and define `INVALID_HANDLE_VALUE` ourselves)
- #117940 (chore: remove unnecessary drop)
- #118028 (Document behavior of `<dyn Any as Any>::type_id()`)
- #118060 (Use an absolute path to the NUL device)
- #118224 (Sort unstable items last in rustdoc, instead of first)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Sort unstable items last in rustdoc, instead of first
As far as I can tell, this is a bug introduced inadvertently by https://github.com/rust-lang/rust/pull/77817 in Rust 1.49. Older toolchains used to sort unstable items last.
Notice how in the code before that PR, `(Unstable, Stable) => return Ordering::Greater` in src/librustdoc/html/render/mod.rs. Whereas after that PR, `(Unstable, Stable) => return Ordering::Less`.
Compare https://doc.rust-lang.org/1.48.0/std/marker/index.html vs https://doc.rust-lang.org/1.49.0/std/marker/index.html.
|
|
Use an absolute path to the NUL device
While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
r? libs
|
|
Document behavior of `<dyn Any as Any>::type_id()`
See also #57893
`@rustbot` label A-docs T-libs
|
|
chore: remove unnecessary drop
No need to manually drop since it's implicit.
|
|
Update windows-bindgen and define `INVALID_HANDLE_VALUE` ourselves
We generate bindings to the Windows API via the `windows-bindgen` crate, which is ultimately what's also used to generate the `windows-sys` and `windows` crates. However, there currently is some custom sauce just for std which makes it a bit different from the vanilla bindings. I would love for us to reduce and eventually remove the differences entirely so that std is using the exact same bindings as everyone else. Maybe in the future we can even just have a normal dependency on `windows-sys`.
This PR removes one of those special things. Our definition of `INVALID_HANDLE_VALUE` relies on an experimental nightly feature for strict provenance, so lets bring that back in house. It also excludes it from the codegen step though that isn't strictly necessary as we override it in any case.
This PR also updates windows-bingen to 0.52.0.
|
|
Improve rewind documentation
The persistent use of an internal cursor for readers is expected for buffer data types that aren't read all at once, but for files it leads to the confusing situation where calling `read_to_end` on the same file handle multiple times only returns the contents of the file for the first call. This PR adds a note to the documentation clarifying that in that case, `rewind()` must first be called.
I'm unsure if this is the right location for the docs update. Maybe it should also be duplicated on `File`?
|
|
Refactor `binary_search_by` to use conditional moves
Refactor the if/else checking on `cmp::Ordering` variants to a "branchless" reassignment of left and right.
This change results in fewer branches and instructions.
https://rust.godbolt.org/z/698eYffTx
---
I saw consistent benchmark improvements locally. Performance of worst case seems about the same, maybe slightly faster for the L3 test.
Current
```
slice::binary_search_l1 43.00ns/iter +/- 3.00ns
slice::binary_search_l1_with_dups 25.00ns/iter +/- 0.00ns
slice::binary_search_l1_worst_case 10.00ns/iter +/- 0.00ns
slice::binary_search_l2 64.00ns/iter +/- 1.00ns
slice::binary_search_l2_with_dups 42.00ns/iter +/- 0.00ns
slice::binary_search_l2_worst_case 16.00ns/iter +/- 0.00ns
slice::binary_search_l3 132.00ns/iter +/- 2.00ns
slice::binary_search_l3_with_dups 108.00ns/iter +/- 2.00ns
slice::binary_search_l3_worst_case 33.00ns/iter +/- 3.00ns
```
This PR
```
slice::binary_search_l1 21.00ns/iter +/- 0.00ns
slice::binary_search_l1_with_dups 14.00ns/iter +/- 0.00ns
slice::binary_search_l1_worst_case 9.00ns/iter +/- 0.00ns
slice::binary_search_l2 34.00ns/iter +/- 0.00ns
slice::binary_search_l2_with_dups 23.00ns/iter +/- 0.00ns
slice::binary_search_l2_worst_case 16.00ns/iter +/- 0.00ns
slice::binary_search_l3 92.00ns/iter +/- 3.00ns
slice::binary_search_l3_with_dups 63.00ns/iter +/- 1.00ns
slice::binary_search_l3_worst_case 29.00ns/iter +/- 0.00ns
```
|
|
Cache flags for `ty::Const`
Not sure if this has been attempted yet, but worth a shot. It does make the code simpler in `rustc_type_ir`, since we can assume that consts have a `flags` method that is no-cost.
r? `@ghost`
|
|
This allows LLVM to optimize comparisons to zero before & after the
multiplication into one, saving on code size and eliminating an (always
true) branch from most Vec allocations.
|
|
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 4)
Follow up
* https://github.com/rust-lang/rust/pull/116214
* https://github.com/rust-lang/rust/pull/116432
* https://github.com/rust-lang/rust/pull/116824
|
|
|
|
|
|
Fix fn_sig_for_fn_abi and the coroutine transform for generators
There were three issues previously:
* The self argument was pinned, despite Iterator::next taking an unpinned mutable reference.
* A resume argument was passed, despite Iterator::next not having one.
* The return value was CoroutineState<Item, ()> rather than Option<Item>
While these things just so happened to work with the LLVM backend, cg_clif does much stricter checks when trying to assign a value to a place. In addition it can't handle the mismatch between the amount of arguments specified by the FnAbi and the FnSig.
|
|
Add `BufRead::skip_until`
Alternative version of `BufRead::read_until` that simply discards data, rather than copying it into a buffer.
Useful for situations like skipping irrelevant data in a binary file format that is NUL-terminated.
<details>
<summary>Benchmark</summary>
```
running 2 tests
test bench_read_until ... bench: 123 ns/iter (+/- 6)
test bench_skip_until ... bench: 66 ns/iter (+/- 3)
```
```rs
#![feature(test)]
extern crate test;
use test::Bencher;
use std::io::{ErrorKind, BufRead};
fn skip_until<R: BufRead + ?Sized>(r: &mut R, delim: u8) -> Result<usize, std::io::Error> {
let mut read = 0;
loop {
let (done, used) = {
let available = match r.fill_buf() {
Ok(n) => n,
Err(ref e) if e.kind() == ErrorKind::Interrupted => continue,
Err(e) => return Err(e),
};
match memchr::memchr(delim, available) {
Some(i) => (true, i + 1),
None => (false, available.len()),
}
};
r.consume(used);
read += used;
if done || used == 0 {
return Ok(read);
}
}
}
const STR: &[u8] = b"Ferris\0Hello, world!\0";
#[bench]
fn bench_skip_until(b: &mut Bencher) {
b.iter(|| {
let mut io = std::io::Cursor::new(test::black_box(STR));
skip_until(&mut io, b'\0').unwrap();
let mut hello = Vec::with_capacity(b"Hello, world!\0".len());
let num_bytes = io.read_until(b'\0', &mut hello).unwrap();
assert_eq!(num_bytes, b"Hello, world!\0".len());
assert_eq!(hello, b"Hello, world!\0");
});
}
#[bench]
fn bench_read_until(b: &mut Bencher) {
b.iter(|| {
let mut io = std::io::Cursor::new(test::black_box(STR));
io.read_until(b'\0', &mut Vec::new()).unwrap();
let mut hello = Vec::with_capacity(b"Hello, world!\0".len());
let num_bytes = io.read_until(b'\0', &mut hello).unwrap();
assert_eq!(num_bytes, b"Hello, world!\0".len());
assert_eq!(hello, b"Hello, world!\0");
});
}
```
</details>
|
|
|
|
Previously, the tidy tool would fault if an untracked file had a space
or other special characters in its name. If there was an untracked file
"foo bar", it would include the quoting in it's path and split on the
first space, giving output like this:
`skip untracked path "foo during rustfmt invocations`
|
|
|
|
|
|
|
|
Fix tracking issue of Windows ExitCodeExt
Tracking issue: https://github.com/rust-lang/rust/issues/111688
This was left out of the initial ExitCodeExt implementation in https://github.com/rust-lang/rust/pull/97917.
|
|
|
|
There were three issues previously:
* The self argument was pinned, despite Iterator::next taking an
unpinned mutable reference.
* A resume argument was passed, despite Iterator::next not having one.
* The return value was CoroutineState<Item, ()> rather than Option<Item>
While these things just so happened to work with the LLVM backend,
cg_clif does much stricter checks when trying to assign a value to a
place. In addition it can't handle the mismatch between the amount of
arguments specified by the FnAbi and the FnSig.
|
|
|
|
Don't print "private fields" on empty tuple structs
Closes #118180.
While working on this I also noticed that empty struct variants are also rendered rather awkwardly. I'll make another issue for that, since I don't know what the correct rendering would be.
|
|
Add an experimental feature gate for function delegation
In accordance with the [process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).
Detailed description of the feature can be found in the RFC repo - https://github.com/rust-lang/rfcs/pull/3530.
TODO: find a lang team liaison - https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/fn.20delegation.20liaison/near/402506959.
|
|
Test for presence rather than absence
Remove redundant tests
Issues in those parts will likely be caught by other parts of the test suite.
|
|
In accordance with the [process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).
Detailed description of the feature can be found in the RFC repo - https://github.com/rust-lang/rfcs/pull/3530.
|
|
improve bootstrap change-tracking system
This PR aims to improve how change-tracking system works for bootstrap changes by doing the followings:
- Enforce embedding directive informations about the changes on `bootstrap/src/lib.rs`.
- Give more informative change inputs on the terminal (https://github.com/rust-lang/rust/pull/117815#discussion_r1390239657).
- Avoid spamming the change informations(by reading and creating `.last-warned-change-id` under build output dir).
see the zulip conversation for more details: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/config.2Etoml.20change.20tracking
cc `@RalfJung`
|
|
|
|
|
|
Pass flags to `rustdoc` shim without env. vars
Discussed here: https://github.com/rust-lang/rust/pull/116448#issuecomment-1748785961. Since it was not really documented why these flags were passed through the shim, I guess that the only way to find out if it's really needed... is to remove it :)
r? `@petrochenkov`
|
|
|
|
Miri: GC the dead_alloc_map too
dead_alloc_map is the last piece of state in the interpreter I can find that leaks. With this PR, all of the long-term memory growth I can find in Miri with programs that do things like run a big `loop {` or run property tests is attributable to some data structure properties in borrow tracking, and is _extremely_ slow.
My only gripe with the commit in this PR is that I don't have a new test for it. I'd like to have a regression test for this, but it would have to be statistical I think because the peak memory of a process that Linux reports is not exactly the same run-to-run. Which means it would have to not be very sensitive to slow leaks (some guesswork suggests for acceptable CI time we would be checking for like 10% memory growth over a minute or two, which is still pretty fast IMO).
Unless someone has a better idea for how to detect a regression, I think on balance I'm fine with manually keeping an eye on the memory use situation.
r? RalfJung
|
