| Age | Commit message (Collapse) | Author | Lines |
|---|
|
A bit of spell-checking
I noticed the one error in miri-script and took care of a few more shallow ones.
|
|
Automatic sync from rustc
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #113534 (Forbid old-style `simd_shuffleN` intrinsics)
- #113999 (Specify macro is invalid in certain contexts)
- #114348 (Migrate GUI colors test to original CSS color format)
- #114373 (unix/kernel_copy.rs: copy_file_range_candidate allows empty output files)
- #114404 (Migrate GUI colors test to original CSS color format)
- #114409 (builtin impl confirmation wuhu)
- #114429 (compiletest: Handle non-utf8 paths (fix FIXME))
- #114431 (Enable tests on rustc_codegen_ssa)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Enable tests on rustc_codegen_ssa
This enables unittests in rustc_codegen_ssa. There are some tests, primarily in [`back/rpath/tests.rs`](https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_codegen_ssa/src/back/rpath/tests.rs) that haven't ever been running since the unittests are disabled. From what I can tell, this was just a consequence of how things evolved. When testing was initially added in https://github.com/rust-lang/rust/pull/33282, `librustc_trans` had test=false because it didn't have any tests. `rustc_codegen_ssa` eventually split off from that (https://github.com/rust-lang/rust/pull/55627), and the rpath module eventually got merged in too (from `librustc_back` where it used to live). That migration didn't enable the tests.
This also includes some fluent diagnostic tests, though I'm not sure what exactly they are testing.
|
|
compiletest: Handle non-utf8 paths (fix FIXME)
Removes the last FIXME in the code for #9639 🎉 (which was closed 8 years ago)
Part of #44366 which is E-help-wanted.
(The other two PRs that does this are #114377 and #114427)
|
|
builtin impl confirmation wuhu
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
Seems like this one was forgotten...
r? `@notriddle`
|
|
unix/kernel_copy.rs: copy_file_range_candidate allows empty output files
This is for https://github.com/rust-lang/rust/issues/114341
The `meta.len() > 0` condition here is intended for inputs only, ie. when input is in the `/proc` filesystem as documented.
That inaccurately included empty output files which are then shunted to the sendfile() routine leading to higher than nescessary IO util in some cases, specifically with CoW filesystems like btrfs.
Simply, determine what is input or output given the passed boolean.
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
Specify macro is invalid in certain contexts
Adds a note when a macro is used where it really shouldn't be.
Closes #113766
|
|
Forbid old-style `simd_shuffleN` intrinsics
Don't merge before https://github.com/rust-lang/packed_simd/pull/350 has made its way to crates.io
We used to support specifying the lane length of simd_shuffle ops by attaching the lane length to the name of the intrinsic (like `simd_shuffle16`). After this PR, you cannot do that anymore, and need to instead either rely on inference of the `idx` argument type or specify it as `simd_shuffle::<_, [u32; 16], _>`.
r? `@workingjubilee`
|
|
Strip unexpected debuginfo from `libLLVM.so` and `librustc_driver.so` when not requesting any debuginfo
As seen in #114175 and in [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Artifact.20sizes/near/379302655), there's still some small amount of debuginfo in LLVM's shared library on linux, even when not requesting it (nightly CI), coming from `libstdc++`.
```
$ readelf --debug-dump=info ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-16-rust-1.73.0-nightly.so | grep DW_TAG_compile_unit -A5 | grep DW_AT_comp_dir | cut -d ":" -f 2- | counts
101 counts
( 1) 39 (38.6%, 38.6%): (indirect string, offset: 0x7): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++
( 2) 38 (37.6%, 76.2%): (indirect string, offset: 0x43fb2): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11
( 3) 23 (22.8%, 99.0%): (indirect string, offset: 0x18ed8): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98
( 4) 1 ( 1.0%,100.0%): (indirect string, offset: 0x53f04): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
```
Similarly, here's `librustc_driver.so` when not requesting debuginfo from either rustc or the tools (nightly CI), coming e.g. from our LLVM wrapper:
```
$ readelf --debug-dump=info ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-e534b3a316089f5f.so | grep DW_TAG_compile_unit -A5 | grep DW_AT_comp_dir | cut -d ":" -f 2- | counts
116 counts
( 1) 34 (29.3%, 29.3%): (indirect string, offset: 0x3c11): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++
( 2) 32 (27.6%, 56.9%): (indirect string, offset: 0x9753c): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11
( 3) 25 (21.6%, 78.4%): (indirect string, offset: 0x393bd): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98
( 4) 23 (19.8%, 98.3%): (indirect string, offset: 0x33ed3): /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.98
( 5) 1 ( 0.9%, 99.1%): (indirect string, offset: 0xaffff): /rustc/0d95f9132909ae7c5f2456748d0ffd1c3ba4a8e8
( 6) 1 ( 0.9%,100.0%): (indirect string, offset: 0xb604a): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
```
To reduce the size of distributed artifacts, this PR strips debuginfo from the LLVM and `rustc_driver` shared libraries, when:
- no debuginfo is requested when building LLVM: `link-shared` is true, `optimize` is true and `release-debuginfo` is false
- no debuginfo is requested when building the rustc driver:
- `debuginfo-level-rustc` and `debuginfo-level-tools` are off.
- when building with a stage != 0 compiler: since this is about the distributed artifacts, there's no need to do this at other stages.
- for both: on a x64 linux host and target where `strip -g` is available and fixes the issue (I don't know how to strip debuginfo from a `.dylib` on mac). The LLVM BOLTed .so, and `librustc_driver.so` are big there, and this will help a little. Other targets/hosts can be added in the future if we want to.
#114175 did the same thing unconditionally in `opt-dist`, prior to BOLTing LLVM. But this should only be used in conjunction with the other config options mentioned above, and which `opt-dist` doesn't know about. Therefore, it makes more sense as in bootstrap when building LLVM and rustc when applicable and no debuginfo is requested.
This shouldn't interact badly with CI caching builds and artifacts, right?
---
From the other PR, `libLLVM-16-rust-1.73.0-nightly.so` prior to #114141:
- master: 173.13 MiB
- stripped debuginfo: 165.12 MiB (-8 MiB, -4.6%)
`libLLVM-16-rust-1.73.0-nightly.so` after #114141:
- master: 121.13 MiB
- stripped debuginfo: 113.12 MiB (still -8 MiB, -6.6%)
`librustc_driver.so`:
- master: 118.58 MiB
- stripped debuginfo: 106.46 MiB (-12 MiB, -10.2%)
(Results are also available in this most recent [perf run's artifact sizes](https://perf.rust-lang.org/compare.html?start=b321edd1b2d4bd00c7b4611e8f20a03ee7b77023&end=810ab570d5d27facb91806e5d9847815d9dac22a&stat=instructions%3Au&tab=artifact-size))
|
|
Only unpack tupled args in inliner if we expect args to be unpacked
`"rust-call"` is a strange function abi. sometimes, it expects the arguments to be unpacked by the caller and passed as individual args (closure bodies), and sometimes it does not (user functions annotated with the `"rust-call"` abi).
make sure the mir inliner respects this difference when checking that arguments are compatible, and doesn't try to ICE when we call a `extern "rust-call"` function in a generic context.
fixes #110829
|
|
This is for https://github.com/rust-lang/rust/issues/114341
The `meta.len() > 0` condition here is intended for inputs only,
ie. when input is in the `/proc` filesystem as documented.
That inaccurately included empty output files which are then shunted to
the sendfile() routine leading to higher than nescessary IO util in some
cases, specifically with CoW filesystems like btrfs.
Further, `NoneObtained` is not relevant in this context, so remove it.
Simply, determine what is input or output given the passed enum Unit.
|
|
Add `internal_features` lint
Implements https://github.com/rust-lang/compiler-team/issues/596
Also requires some more test blessing for codegen tests etc
`@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #113657 (Expand, rename and improve `incorrect_fn_null_checks` lint)
- #114237 (parser: more friendly hints for handling `async move` in the 2015 edition)
- #114300 (Suggests turbofish in patterns)
- #114372 (const validation: point at where we found a pointer but expected an integer)
- #114395 ([rustc_span][perf] Hoist lookup sorted by words out of the loop.)
- #114403 (fix the span in the suggestion of remove question mark)
- #114408 (Temporary remove myself from review rotation)
- #114415 (Skip checking of `rustc_codegen_gcc` with vendoring enabled)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update cargo (CVE-2023-38497 fix included)
2 commits in 020651c52257052d28f6fd83fbecf5cfa1ed516c..d78bbf4bde3c6b95caca7512f537c6f9721426ff
2023-08-02 16:00:37 +0000 to 2023-08-03 12:58:25 +0000
- Fix CVE-2023-38497 for master (rust-lang/cargo#12443)
- Don't attempt to read a token from stdin if a cmdline token is provided (rust-lang/cargo#12440)
r? `@ghost`
|
|
Skip checking of `rustc_codegen_gcc` with vendoring enabled
`rustc_codegen_gcc` currently cannot be vendored, which [breaks](https://github.com/rust-lang/rust/issues/112393) `x.py check` with vendoring enabled. Until the vendoring issue is resolved, it would be nice if `x.py check` could succeed (and just skip `gcc`) with `vendor = true`. With this PR, it does.
Related issue: https://github.com/rust-lang/rust/issues/112393
r? bootstrap
|
|
Temporary remove myself from review rotation
I'm going on vacation from 7-th to 15-th and won't be reviewing PRs or writing code.
Feel free to still ping me if you want, I'll read everything when I'm back, but most likely not sooner =)
|
|
fix the span in the suggestion of remove question mark
Fixes #114392
Use a more precise span.
|
|
[rustc_span][perf] Hoist lookup sorted by words out of the loop.
```@lqd``` commented on https://github.com/rust-lang/rust/pull/114351 asking if `sort_by_words(lookup)` is computed repeatedly. I was assuming that rustc should have no difficulties to hoist it automatically outside of the loop to avoid repeated pure computation, but according to
https://godbolt.org/z/frs8Kj1rq it seems like I was wrong:
original version seems to have 2 calls per loop iteration
```
.LBB16_3:
mov rbx, qword ptr [r13]
mov r14, qword ptr [r13 + 8]
lea rdi, [rsp + 40]
mov rsi, rbx
mov rdx, r14
call example::sort_by_words
lea rdi, [rsp + 64]
mov rsi, qword ptr [rsp + 8]
mov rdx, qword ptr [rsp + 16]
call example::sort_by_words
mov rdi, qword ptr [rsp + 40]
mov rdx, qword ptr [rsp + 56]
mov rsi, qword ptr [rsp + 64]
cmp rdx, qword ptr [rsp + 80]
mov qword ptr [rsp + 32], rdi
mov qword ptr [rsp + 24], rsi
jne .LBB16_5
call qword ptr [rip + bcmp@GOTPCREL]
test eax, eax
sete al
mov dword ptr [rsp + 4], eax
mov rsi, qword ptr [rsp + 72]
test rsi, rsi
jne .LBB16_8
jmp .LBB16_9
```
but the manually hoisted version just 1:
```
.LBB16_3:
mov r13, qword ptr [r15]
mov r14, qword ptr [r15 + 8]
lea rdi, [rsp + 64]
mov rsi, r13
mov rdx, r14
call example::sort_by_words
mov rdi, qword ptr [rsp + 64]
mov rdx, qword ptr [rsp + 16]
cmp qword ptr [rsp + 80], rdx
mov qword ptr [rsp + 32], rdi
jne .LBB16_5
mov rsi, qword ptr [rsp + 8]
call qword ptr [rip + bcmp@GOTPCREL]
test eax, eax
sete bpl
mov rsi, qword ptr [rsp + 72]
test rsi, rsi
jne .LBB16_8
jmp .LBB16_9
```
This code is probably not very hot, but there is no reason to leave such a low hanging fruit.
|
|
const validation: point at where we found a pointer but expected an integer
Instead of validation just printing "unable to turn pointer into bytes", make this a regular validation error that says where in the value the bad pointer was found. Also distinguish "expected integer, got pointer" from "expected pointer, got partial pointer or mix of pointers".
To avoid duplicating things too much I refactored the diagnostics for validity a bit, so that "got uninit, expected X" and "got pointer, expected X" can share the "X" part. Also all the errors emitted for validation are now grouped under `const_eval_validation` so that they are in a single group in the ftl file.
r? `@oli-obk`
|
|
Suggests turbofish in patterns
Fixes #114112
r? ```@estebank```
|
|
parser: more friendly hints for handling `async move` in the 2015 edition
Fixes #114219
An error is emitted when encountering an async move block in the 2015 edition.
Another appropriate location to raise an error is after executing [let path = this.parse_path(PathStyle::Expr)?](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/stmt.rs#L152), but it seems somewhat premature to invoke `create_err` at that stage.
|
|
Expand, rename and improve `incorrect_fn_null_checks` lint
This PR,
- firstly, expand the lint by now linting on references
- secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks`
- and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut`
Fixes https://github.com/rust-lang/rust/issues/113601
cc ```@est31```
|
|
|
|
|
|
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
Avoid infinite recursion for auto-fmt and auto-clippy
I got stack overflows after I fixed the `-`/`_` typo 😆
|
|
add test checking that overlapping assignments work
|
|
|
|
|
|
Infer type in irrefutable slice patterns with fixed length as array
Fixes https://github.com/rust-lang/rust/issues/76342
In irrefutable slice patterns with a fixed length, we can infer the type as an array type. We now choose to prefer some implementations over others, e.g. in:
```
struct Zeroes;
const ARR: [usize; 2] = [0; 2];
const ARR2: [usize; 2] = [2; 2];
impl Into<&'static [usize; 2]> for Zeroes {
fn into(self) -> &'static [usize; 2] {
&ARR
}
}
impl Into<&'static [usize]> for Zeroes {
fn into(self) -> &'static [usize] {
&ARR2
}
}
fn main() {
let &[a, b] = Zeroes.into();
}
```
We now prefer the impl candidate `impl Into<&'static [usize; 2]> for Zeroes`, it's not entirely clear to me that this is correct, but given that the slice impl would require a type annotation anyway, this doesn't seem unreasonable.
r? `@lcnr`
|
|
|
|
|
|
jieyouxu:suggestion_macro_expansion_source_callsites, r=cjgillot
Fix suggestion spans for expr from macro expansions
### Issue #112007: rustc shows expanded `writeln!` macro in code suggestion
#### Before This PR
```
help: consider using a semicolon here
|
6 | };
| +
help: you might have meant to return this value
--> C:\Users\hayle\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\macros\mod.rs:557:9
|
55| return $dst.write_fmt($crate::format_args_nl!($($arg)*));
| ++++++ +
```
#### After This PR
```
help: consider using a semicolon here
|
LL | };
| +
help: you might have meant to return this value
|
LL | return writeln!(w, "but not here");
| ++++++ +
```
### Issue #110017: `format!` `.into()` suggestion deletes the `format` macro
#### Before This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
--> /Users/eric/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/macros.rs:121:12
|
12| res.into()
| +++++++
```
#### After This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
|
LL | Err(format!("error: {x}").into())
| +++++++
```
---
Fixes #112007.
Fixes #110017.
|
|
|
|
|
|
|
|
|
