Previously, the result of `predicates_of` for a foreign trait
would depend on the *current* state of the corresponding source
file in the foreign crate. This could lead to ICEs during incremental
compilation, since the on-disk contents of the upstream source file
could potentially change without the upstream crate being recompiled.
Additionally, this ensure that that the metadata we produce for a crate
only depends on its *compiled* upstream dependencies (e.g an rlib or
rmeta file), *not* the current on-disk state of the upstream crate
source files.
We can instead if either the LHS or RHS types contain
`TyKind::Error`. In addition to covering the case where
we would have previously updated `if_let_suggestions`, this might
also prevent redundant errors in other cases as well.
Introduce `~const`
- [x] Removed `?const` and change uses of `?const`
- [x] Added `~const` to the AST. It is gated behind const_trait_impl.
- [x] Validate `~const` in ast_validation.
- [x] Update UI Tests
- [x] Add enum `BoundConstness` (With variants `NotConst` and
`ConstIfConst` allowing future extensions)
- [x] Adjust trait selection and pre-existing code to use `BoundConstness`.
- [ ] Optional steps for this PR
- [x] Fix#88155
- [x] ~~Do something with constness bounds in chalk~~ Must be done to rust-lang/chalk (just tried to refactor, there are a lot of errors to resolve :( )
- [ ] Adjust Error messages for `~const` bounds that can't be satisfied.
r? `@oli-obk`
Tracking issue for `UNSUPPORTED_CALLING_CONVENTIONS`
This was previously forgotten. Nominating for 1.55 as this lint will make it into stable in that release.
r? `@Mark-Simulacrum`
Updated issue templates(formatting and rustbot label reference)
This PR updates our issue templates. The changes are:
1. **Make the *Meta* section smaller and not indented**
The current format sometimes gets messed up when a user simply pasts the rustc version into the issue without indenting it to match the code block. Removing the indention should hopefully help with formatting in the future.
<details><summary>Example of messed up formatting </summary>
![image](https://user-images.githubusercontent.com/17087237/130811809-2b9bc58e-c13f-4338-b34e-18648a5de413.png)
</details>
Additionally, I've removed the Version of Clippy from the template. Every issue that I have seen had matching rustc and Clippy versions, and just asking for `rustc -Vv` makes the issue look cleaner IMO.
2. **Add a comment explaining how additional labels can be added with ``@rustbot` label +<label>`. The explanation looks like this:**
```
<!--
Additional labels can be added to this issue by including the following command:
`@rustbot` label +<label>
Common labels for this issue type are:
* `I-suggestion-causes-error`
-->
```
The example ``@rustbot`` call can sadly not be marked as code inside a comment block. But the example will not cause the bot to add any labels. See rust-lang/rust-clippy#7599
---
changelog: none
cc: `@rust-lang/clippy`
Both the place where the parser encounters a needed closed delimiter and
the unclosed opening delimiter are important, so they should get the
same level of highlighting in the output.
Adjust linking order of static nobundle libraries
Link the static libraries with "-bundle" modifier from upstream rust crate right after linking this rust crate.
Some linker such as GNU linker `ld.bdf` treat order of linking as order of dependency.
After this change, static libraries with "-bundle" modifier is linked in the same order as "+bundle" modifier.
So we can change the value of "bundle" modifier without causing linking error.
fix: https://github.com/rust-lang/rust/issues/87541
r? `@petrochenkov`