Rollup of 5 pull requests
Successful merges:
- #113710 (Fix rpath for libdir is specified)
- #113787 (Update documentation for std::process::Command's new method)
- #113795 (Properly document `lifetime_mapping` in `OpaqueTy`)
- #113857 (Add tests for `--document-hidden-items` option)
- #113871 (Use the correct span for displaying the line following a derive sugge…)
r? `@ghost`
`@rustbot` modify labels: rollup
Use the correct span for displaying the line following a derive sugge…
`span` here is the main span of the diagnostic. In the linked issue's case, this belongs to `main.rs`. However, the line numbers (and line we are trying to display) are in `name.rs`, so using `span_to_lines` gives us the wrong `FileLines`.
Use `parts[0].span` (the span of the suggestion) here like the rest of the code does to get the right file.
Not sure if this needs a dedicated test because this fixes an existing error in the UI suite
Fixes#113844
Add tests for `--document-hidden-items` option
Since `--document-hidden-items` was greatly fixed/improved in https://github.com/rust-lang/rust/pull/113574, thought it might be worth adding some more tests for it to prevent new regressions.
As for the first commit, it allows to go from:
```
Traceback (most recent call last):
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 706, in <module>
check(sys.argv[1], get_commands(rust_test_path))
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 689, in check
for c in commands:
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 274, in get_commands
args = shlex.split(args)
File "/usr/lib/python3.10/shlex.py", line 315, in split
return list(lex)
File "/usr/lib/python3.10/shlex.py", line 300, in __next__
token = self.get_token()
File "/usr/lib/python3.10/shlex.py", line 109, in get_token
raw = self.read_token()
File "/usr/lib/python3.10/shlex.py", line 191, in read_token
raise ValueError("No closing quotation")
ValueError: No closing quotation
```
to:
```
Traceback (most recent call last):
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 708, in <module>
check(sys.argv[1], get_commands(rust_test_path))
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 691, in check
for c in commands:
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 278, in get_commands
raise Exception("line {}: {}".format(lineno + 1, exc)) from None
Exception: line 57: No closing quotation
```
Having the line where the error occurred is quite useful.
r? `@notriddle`
Properly document `lifetime_mapping` in `OpaqueTy`
Also use an `Option` to signify that the value is actually present, instead of just no captured lifetimes.
Update documentation for std::process::Command's new method
In the current documentation, it's not specified that when creating a Command, the .exe extension can be omitted for Windows executables. However, for other types of executable files like .bat or .cmd, the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()` succeeds on my machine while `Command::new("code").spawn().unwrap()` panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in [a comment](e7fda447e7/library/std/src/sys/windows/process.rs (L425)), but it makes sense to mention it at a more visible place.
I've added this clarification to the documentation, which should make it more accurate and helpful for Rust developers working on the Windows platform.
Fix rpath for libdir is specified
## What does this PR try to resolve?
When building the Rust toolchain with `--libdir=lib64`, the executable tools such as `rustc` cannot find shared libraries.
```bash
./configure --prefix=/ --libdir=lib64
DESTDIR=/tmp/rust ./x.py install
```
```
$ /tmp/rust/bin/rustc
rustc: error while loading shared libraries: librustc_driver-13f1fd1bc7f7000d.so: cannot open shared object file: No such file or directory
```
This issue is caused by the link args `-Wl,rpath` being different from `--libdir`.
```
$ readelf -d /tmp/rust/bin/rustc | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib]
```
## How to resolve?
When setting the rpath, get it from sysroot libdir relative path.
After this patch:
```
$ readelf -d /tmp/rust/bin/rustc | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib64]
```
On nightly, dump ICE backtraces to disk
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.
<img width="1032" alt="Screenshot 2023-03-03 at 2 13 25 PM" src="https://user-images.githubusercontent.com/1606434/222842420-8e039740-4042-4563-b31d-599677171acf.png">
The current behavior will *always* write to disk on nightly builds, regardless of whether the backtrace is printed to the terminal, unless the environment variable `RUSTC_ICE_DISK_DUMP` is set to `0`. This is a compromise and can be changed.
Rollup of 7 pull requests
Successful merges:
- #113444 (add tests for alias bound preference)
- #113716 (Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.)
- #113754 (Simplify native_libs query)
- #113765 (Make it clearer that edition functions are `>=`, not `==`)
- #113774 (Improve error message when closing bracket interpreted as formatting fill character)
- #113785 (Fix invalid display of inlined re-export when both local and foreign items are inlined)
- #113803 (Fix inline_const with interpolated block)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix inline_const with interpolated block
Interpolation already worked when we had a `const $block` that wasn't a statement expr:
```
fn foo() {
let _ = const $block;
}
```
But it was failing when the const block was in statement expr position:
```
fn foo() {
const $block;
}
```
... because of a bug in a check for const items. This fixes that.
---
cc https://github.com/rust-lang/rust/pull/112953#issuecomment-1631354481, though I don't think this requires an FCP since it's already supported in exprs and seems to me to be fully a parser bug.
Fix invalid display of inlined re-export when both local and foreign items are inlined
Fixes#105735.
The bug is actually quite interesting: at the `clean` pass, local inlined items have their `use` item removed, however foreign items don't have their `use` item removed because it's in the `clean` pass that we handle them. So when a `use` inlines both a local and a foreign item, it will work as expected for the foreign one, but not for the local as its `use` should not be around anymore.
To prevent this, I created a new `inlined_foreigns` field into the `Module` struct to allow to remove the `use` item early on for foreign items as well. Then we iterate it in the `clean` pass directly.
r? ``@notriddle``
Make it clearer that edition functions are `>=`, not `==`
r? `@Nilstrieb`
We could also perhaps derive `Ord` on `Edition` and use comparison operators.
Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.
**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**
This is also the reason why no_builtins does not take effect in LTO as mentioned in #35540.
Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.
Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.
We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.
Related discussions:
- #109821
- #35540
Next (a separate pull request?):
- [ ] Revert #35637
- [ ] Add a function-level `no_builtin` attribute?
Encode shorthands for spans in metadata.
Spans occupy a typically large proportion of metadata.
This PR deduplicates encoded spans in order to reduce encoded length.
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
Better diagnostics for dlltool errors.
When dlltool fails, show the full command that was executed. In particular, llvm-dlltool is not very helpful, printing a generic usage message rather than what actually went wrong, so stdout and stderr aren't of much use when troubleshooting.
allow opaques to be defined by trait queries, again
This basically reverts #112963.
Moreover, all call-sites of `enter_canonical_trait_query` can now define opaque types, see the ui test `defined-by-user-annotation.rs`.
Fixes#113689
r? `@compiler-errors` `@oli-obk`
Instead of repeatedly merging the two smallest CGUs, we now use a
merging algorithm that aims to minimize the duplication of inlined
functions.
`exa-0.10.1` was one benchmark that saw particularly good results. The
old CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3834 (1216 root + 2618 inlined), placed size: 154552 (77219 root + 77333 inlined)
- placed/unique items ratio: 1.38, placed/unique size ratio: 1.27
- CGUs: 16, mean size: 9659.5, sizes: [11791, 11634, 11173, 10987, 10939, 10507, 9992, 9813, 9593, 9580, 9030, 8447, 7975, 7961, 7876, 7254]
```
The new CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3626 (1216 root + 2410 inlined), placed size: 147201 (77219 root + 69982 inlined)
- placed/unique items ratio: 1.31, placed/unique size ratio: 1.21
- CGUs: 16, mean size: 9200.1, sizes: [11634, 10939, 10227, 9555, 9178, 9167, 8879, 8804, 8604, 8603 (x3), 8602 (x2), 8601, 8600]
```
The difference is in the number of inlined items. There are 1558 unique
inlined items. With the old algorithm these were placed 2618 times,
resulting in 1060 duplicates. With the new algorithm these were placed
2410 times, resulting in 852 duplicates. Also, the mean CGU size dropped
from 9659.5 to 9200.1, and the CGU size distribution tightened, with the
biggest one a little smaller and the smallest ones a little bigger.
Restrict recursive opaque type check
We have a recursive opaque check in writeback to avoid inferring the hidden of an opaque type to be itself:
33a2c2487a/compiler/rustc_hir_typeck/src/writeback.rs (L556-L575)
Issue #113619 treats `make_option2` as not defining the TAIT `TestImpl` since it is inferred to have the definition `TestImpl := B<TestImpl>`, which fails this check. This regressed in #102700 (5d15beb591), I think due to the refactoring that made us record the hidden types of TAITs during writeback.
However, nothing actually seems to go bad if we relax this recursion checker to only check for directly recursive definitions. This PR fixes#113619 by changing this recursive check from being a visitor to just checking that the hidden type is exactly the same as the opaque being inferred.
Alternatively, we may be able to fix#113619 by restricting this recursion check only to RPITs/async fns. It seems to only be possible to use misuse the recursion check to cause ICEs for TAITs (though I didn't try too hard to create a bad RPIT example... may be possible, actually.)
r? `@oli-obk`
--
Fixes#113314
