new solver: don't consider blanket impls multiple times
only consider candidates which rely on the self type in `assemble_candidates_after_normalizing_self_ty`.
r? ``@compiler-errors``
rustdoc: fix position of `default` in method rendering
With the following code:
```rs
#![feature(specialization)]
pub trait A {
unsafe fn a();
}
impl A for () {
default unsafe fn a() {}
}
```
rustdoc would render the `impl` of `a` as
```rs
unsafe default fn a()
```
which is inconsistent with the actual position of `default`.
This PR fixes this issue.
Turn copy into moves during DSE.
Dead store elimination computes whether removing a direct store to an unborrowed place is allowed.
Where removing a store is allowed, writing `uninit` is too.
This means that we can use this pass to transform `copy` operands into `move` operands. This is only interesting in call terminators, so we only handle those.
Special care is taken for the `use_both(_1, _1)` case:
- moving the second argument is ok, as `_1` is not live after the call;
- moving the first argument is not, as the second argument reads `_1`.
Fixes#75993
Fixes https://github.com/rust-lang/rust/issues/108068
r? `@RalfJung`
cc `@JakobDegen`
Verify that all crate sources are in sync
This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib.
Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
Fixes https://github.com/rust-lang/rust/issues/10786
Fixes https://github.com/rust-lang/rust/issues/82151
Fixes https://github.com/rust-lang/rust/issues/82972
Closes https://github.com/bevy-cheatbook/bevy-cheatbook/issues/114
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.
This ensures that rustc will not attempt to link against a cdylib as if
it is a rust dylib when an rlib for the same crate is available.
Previously rustc didn't actually check if any further formats of a
crate which has been loaded are of the same version and if they are
actually valid. This caused a cdylib to be interpreted as rust dylib as
soon as the corresponding rlib was loaded. As cdylibs don't export any
rust symbols, linking would fail if rustc decides to link against the
cdylib rather than the rlib.
Two crates depended on the previous behavior by separately compiling a
test crate as both rlib and dylib. These have been changed to capture
their original spirit to the best of my ability while still working
when rustc verifies that all crates are in sync. It is unlikely that
build systems depend on the current behavior and in any case we are
taking a lot of measures to ensure that any change to either the source
or the compilation options (including crate type) results in rustc
rejecting it as incompatible. We merely didn't do this check here for
now obsolete perf reasons.
