rustc_llvm: unwrap LLVMMetadataRef before casting
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:
```
llvm-wrapper/RustWrapper.cpp:939:31: required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
1301 | struct is_base_of
| ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
from llvm-wrapper/LLVMWrapper.h:1,
from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
| ^~~~~~~~~~~~~~~~~~
```
[reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124
A simple `unwrap` fixes the issue.
r? `@eddyb`
Suggest calling associated `fn` inside `trait`s
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
Added fixes to documentation of `BitAnd`, `BitOr`, `BitXor` and
`BitAndAssign`, where the documentation for implementation on
`Vector<bool>` was using logical operators in place of the bitwise
operators.
r? @steveklabnik
cc #78619
Before #78430, string literals worked because `specialize_constructor`
didn't actually care too much which constructor was passed to it unless
needed. Since then, string literals are special cased and a bit hacky. I
did not anticipate patterns for the `&str` type other than string
literals, hence this bug. This makes string literals less hacky.
Assert that locals have storage when used
The validator in visit_local asserts that local has a stroage when used,
but visit_local is never called so validation is ineffective.
Use super_statement and super_terminator to ensure that locals are visited.
The validator in visit_local asserts that local has a stroage when used,
but visit_local is never called so validation is ineffective.
Use super_statement and super_terminator to ensure that locals are visited.
The previous recursive approach might overflow the stack when walking a
particularly deep, list-like, graph. In particular, dominator
calculation for borrow checking does such a traversal and very long
functions might lead to a region dependency graph with in this
problematic structure.
Rollup of 7 pull requests
Successful merges:
- #74622 (Add std::panic::panic_any.)
- #77099 (make exp_m1 and ln_1p examples more representative of use)
- #78526 (Strip tokens from trait and impl items before printing AST JSON)
- #78550 (x.py setup: Create config.toml in the current directory, not the top-level directory)
- #78577 (validator: Extend aliasing check to a call terminator)
- #78581 (Constantify more BTreeMap and BTreeSet functions)
- #78587 (parser: Cleanup `LazyTokenStream` and avoid some clones)
Failed merges:
r? `@ghost`
I found the description as it stands a bit confusing. I've added a bit more explanation to make it clear that a trailing line ending does not produce a final empty line.
This lets rustc users tweak whether the linker should relax ELF relocations,
namely whether it should emit R_X86_64_GOTPCRELX relocations instead of
R_X86_64_GOTPCREL, as the former is allowed by the ABI to be further
optimised. The default value is whatever the target defines.
std::format and core::write macros' docs linked to core::fmt for format string reference, even though only std::fmt has format string documentation and the link titles were std::fmt.
Constantify more BTreeMap and BTreeSet functions
Just because we can:
- `BTreeMap::len`
- `BTreeMap::is_empty`
- `BTreeSet::len`
- `BTreeSet::is_empty`
Note that I put the `const` under `const_btree_new`, because I don't think their is a need to create another feature flag for that.
cc #71835
x.py setup: Create config.toml in the current directory, not the top-level directory
See https://github.com/rust-lang/rust/issues/78509 for discussion.
r? @pnkfelix
cc @cuviper @Mark-Simulacrum
make exp_m1 and ln_1p examples more representative of use
With this PR, the examples for `exp_m1` would fail if `x.exp() - 1.0` is used instead of `x.exp_m1()`, and the examples for `ln_1p` would fail if `(x + 1.0).ln()` is used instead of `x.ln_1p()`.
Add std::panic::panic_any.
The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`.
Alternative names:
- `panic_with!(..)`
- ~~`start_unwind(..)`~~ (panicking doesn't always unwind)
- `throw!(..)`
- `panic_throwing!(..)`
- `panic_with_value(..)`
- `panic_value(..)`
- `panic_with(..)`
- `panic_box(..)`
- `panic(..)`
The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`.
I suggest `panic_any`, because it allows for any (`Any + Send`) type.
_Tracking issue: #78500_
