Dont ICE for `dyn* Trait: Trait` (built-in object) goals during selection in new trait solver
We were ICEing too eagerly during selection for `dyn*` goals -- both for dyn unsizing candidates and for built-in object candidates. The former should only be performed on `dyn` objects, but the latter are totally fine.
fix compiletest crash
### Motivation
When running compiler-tests locally for the `wasm32` platform, one test repeatedly crashed. It does not crash on the CI, only locally. Investigation shows that the `compiletest` itself crashes
> panicked-at-attempt-to-subtract-with-overflow
```rust
let mut head = replace(bytes, Vec::new());
let mut middle = head.split_off(HEAD_LEN);
// The following line will panic
let tail = middle.split_off(middle.len() - TAIL_LEN).into_boxed_slice();
let skipped = new_len - HEAD_LEN - TAIL_LEN;
```
### Background
The code in question collects the output of a process. Small output is kept completely, but larger output is kept only partially: the first 160 kB and the last 256 kB.
The code that performs this split crashes if the data size is less than 416 kB. There is an early out based on the "filtered" length, but it is possible that the filtered length is greater than the real length. It seems that this code was written with the assumption that the filtered length is larger than the real length, which is not true in general.
When running CI tests locally using `src/ci/docker/run.sh`, the filtered folder is `/checkout`, which is shorter than the placeholder length of 32 bytes.
### Note
This PR should not change any behaviour. It only adds an early our for a case which will definitely crash (at least if compiletest is build with integer checks).
Note that an early out makes sense here: If the real data is too small, it does not sense to split it.
Fix the tests-listing-format-json test on Windows
tests/ui/test-attrs/tests-listing-json-format.rs was failing on Windows because each path in the json-formatted output contained "\\\\" instead of "\\". `runtest::TestCx::normalize_output` already checks the compile flags for json-related arguments to handle this case, so I added an equivalent check for the new run flag.
Move `TyCtxt::mk_x` to `Ty::new_x` where applicable
Part of rust-lang/compiler-team#616
turns out there's a lot of places we construct `Ty` this is a ridiculously huge PR :S
r? `@oli-obk`
Move `TyCtxt::mk_x` to `Ty::new_x` where applicable
Part of rust-lang/compiler-team#616
turns out there's a lot of places we construct `Ty` this is a ridiculously huge PR :S
r? `@oli-obk`
editor/code: Enable `--noUncheckedIndexedAccess` & `--noPropertyAccessFromIndexSignature` ts option
This enables typescript's these option:
- [`--noUncheckedIndexedAccess`](https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess)
- This checks whether indexed access is not `null` (or `undefined`) strictly just as like checking by `std::option::Option::unwrap()`.
- [`--noPropertyAccessFromIndexSignature`](https://www.typescriptlang.org/tsconfig#noPropertyAccessFromIndexSignature)
- This disallows `bar.foo` access if the `bar` type is `{ [key: string]: someType; }`.
----
Additionally, to enable `--noUncheckedIndexedAccess` easily, this pull request introduces [option-t](https://www.npmjs.com/package/option-t) as a dependency instead of defining a function in this repository like `unwrapUndefinable()` .
I'll remove it and define them byself if our dependency management policy is that to avoid to add a new package as possible.
Rollup of 9 pull requests
Successful merges:
- #111119 (style-guide: Add chapter about formatting for nightly-only syntax)
- #112791 (llvm ffi: Expose `CallInst->setTailCallKind`)
- #113145 (style-guide: Document newline rules for assignment operators)
- #113163 (Add a regression test for #112895)
- #113332 (resolve: Use `Interned` for some interned structures)
- #113334 (Revert the lexing of `c"…"` string literals)
- #113350 (Fix the issue of wrong diagnosis for extern pub fn)
- #113371 (Fix submodule handling when the current branch is named after a tag)
- #113384 (style-guide: Clarify grammar for small patterns (not a semantic change))
r? `@ghost`
`@rustbot` modify labels: rollup
style-guide: Clarify grammar for small patterns (not a semantic change)
The grammar as written feels ambiguous and confusing, in large part
because it uses square brackets and commas in the names of
non-terminals. Rewrite it to avoid symbols in the names of
non-terminals, and to instead wrap terminals in backquotes.
Also rename "smallntp" to "small_no_tuple" to make it self-describing.
Fix submodule handling when the current branch is named after a tag
If:
1. The current branch has the same name as git tag, and
2. The current branch is set to track a remote other than `origin`, and
3. We try to update a submodule
then we'll get the following error:
```
; x c
Updating submodule src/doc/reference
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
fatal: 'personal' does not appear to be a git repository
fatal: Could not read from remote repository.
```
The problem is that 1. causes `git symbolic-ref --short HEAD` to try and disambiguate the branch from the tag using `heads/branch-name`, which breaks a previous workaround for a bug in `git submodule update` that uses the wrong remote.
Adapt the workaround to strip `heads/` from the output.
Revert the lexing of `c"…"` string literals
Fixes \[after beta-backport\] #113235.
Further progress is tracked in #113333.
This PR *manually* reverts parts of #108801 (since a git-revert would've been too coarse-grained & messy)
and git-reverts #111647.
CC `@fee1-dead` (#108801) `@klensy` (#111647)
r? `@compiler-errors`
`@rustbot` label F-c_str_literals beta-nominated
style-guide: Document newline rules for assignment operators
The style guide gives general rules for binary operators including
assignment, and one of those rules says to put the operator on the
subsequent line; the style guide needs to explicitly state the exception
of breaking *after* assignment operators rather than before.
This is already what rustfmt does and what users do; this fixes the
style guide to match the expected default style.
Specialize `try_destructure_mir_constant` for its sole user (pretty printing)
We can't remove the query, as we need to invoke it from rustc_middle, but can only implement it in mir interpretation/const eval.
r? `@RalfJung` for a first round.
While we could move all the logic into pretty printing, that would end up duplicating a bit of code with const eval, which doesn't seem great either.
Specialize `try_destructure_mir_constant` for its sole user (pretty printing)
We can't remove the query, as we need to invoke it from rustc_middle, but can only implement it in mir interpretation/const eval.
r? `@RalfJung` for a first round.
While we could move all the logic into pretty printing, that would end up duplicating a bit of code with const eval, which doesn't seem great either.
The style guide gave an example of breaking a multi-line chain element
and all subsequent elements to a new line, but that same example and the
accompanying text also had several chain items stacked on the first
line. rustfmt doesn't do this, except when the rule saying to combine
```
shrt
.y()
```
into
```
shrt.y()
```
applies.
The grammar as written feels ambiguous and confusing, in large part
because it uses square brackets and commas in the names of
non-terminals. Rewrite it to avoid symbols in the names of
non-terminals, and to instead wrap terminals in backquotes.
