- 16 8月, 2023 6 次提交
-
-
由 Matthias Krüger 提交于
Fix typos
-
由 Matthias Krüger 提交于
Point at return type when it influences non-first `match` arm When encountering code like ```rust fn foo() -> i32 { match 0 { 1 => return 0, 2 => "", _ => 1, } } ``` Point at the return type and not at the prior arm, as that arm has type `!` which isn't influencing the arm corresponding to arm `2`. Fix #78124.
-
由 Matthias Krüger 提交于
Deny `FnDef` in patterns We can only see these via `const { .. }` patterns, which are unstable. cc #76001 (tracking issue for inline const pats) Fixes #114658 Fixes #114659
-
由 Matthias Krüger 提交于
Point out expectation even if we have `TypeError::RegionsInsufficientlyPolymorphic` just a minor tweak, since saying "one type is more general than the other" kinda sucks if we don't actually point out two types.
-
由 Matthias Krüger 提交于
Fix pthread_attr_union layout on Wasi Fixes https://github.com/rust-lang/rust/issues/114608 Ran the tests as described in https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md?plain=1#L125
-
由 Matthias Krüger 提交于
Improve docs for impl Default for ExitStatus This addresses a review comment in #106425 (which is on the way to being merged I think). Some of the other followup work is more complicated so I'm going to do individual MRs. ~~Note this branch is on top of #106425~~
-
- 15 8月, 2023 34 次提交
-
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #114711 (Infer `Lld::No` linker hint when the linker stem is a generic compiler driver) - #114772 (Add `{Local}ModDefId` to more strongly type DefIds`) - #114800 (std: add some missing repr(transparent)) - #114820 (Add test for unknown_lints from another file.) - #114825 (Upgrade std to gimli 0.28.0) - #114827 (Only consider object candidates for object-safe dyn types in new solver) - #114828 (Probe when assembling upcast candidates so they don't step on eachother's toes in new solver) - #114829 (Separate `consider_unsize_to_dyn_candidate` from other unsize candidates) - #114830 (Clean up some bad UI testing annotations) - #114831 (Check projection args before substitution in new solver) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Ian Jackson 提交于
This lets us put a version on the impl, too.
-
由 bors 提交于
Don't panic in ceil_char_boundary Implementing the alternative mentioned in this comment: https://github.com/rust-lang/rust/issues/93743#issuecomment-1579935853 Since `floor_char_boundary` will always work (rounding down to the length of the string is possible), it feels best for `ceil_char_boundary` to not panic either. However, the semantics of "rounding up" past the length of the string aren't very great, which is why the method originally panicked in these cases. Taking into account how people are using this method, it feels best to simply return the end of the string in these cases, so that the result is still a valid char boundary.
-
由 Mara Bos 提交于
Co-authored-by: NJosh Stone <cuviper@gmail.com>
-
由 Guillaume Gomez 提交于
Check projection args before substitution in new solver Don't ICE when an impl has the wrong kind of GAT arguments r? lcnr
-
由 Guillaume Gomez 提交于
Clean up some bad UI testing annotations These annotations do nothing
😅 -
由 Guillaume Gomez 提交于
Separate `consider_unsize_to_dyn_candidate` from other unsize candidates Move the unsize candidate assembly *just for* `T -> dyn Trait` out of `assemble_candidates_via_self_ty` so that we only consider it once, instead of for every normalization step of the self ty. This makes sure that we don't assemble several candidates that are equal modulo normalization when we really don't care about normalizing the self type of an `T: Unsize<dyn Trait>` goal anyways. Fixes rust-lang/trait-system-refactor-initiative#57 r? lcnr
-
由 Guillaume Gomez 提交于
Probe when assembling upcast candidates so they don't step on eachother's toes in new solver Lack of a probe causes one candidate to disqualify the other due to inference side-effects. r? lcnr
-
由 Guillaume Gomez 提交于
Only consider object candidates for object-safe dyn types in new solver We apparently allow this per RFC2027
💀 r? lcnr -
由 Guillaume Gomez 提交于
Upgrade std to gimli 0.28.0 Gimli 0.28 removed its `From<EndianSlice> for &[u8]` that was the root cause of #113238. This dependency update mirrors rust-lang/backtrace-rs#557, but since that doesn't require any code changes in `backtrace`, we can also apply that right away for our nested `std/backtrace` feature.
-
由 Guillaume Gomez 提交于
Add test for unknown_lints from another file. This adds a test for #84936 which was incidentally fixed via #97266. It is a strange issue where `#![allow(unknown_lints)]` at the crate root was not applying to unknown lints that fired in a non-inline-module. I did not dig further into how #97266 fixed it, but I did verify it. I couldn't find any existing tests which did anything similar. Closes #84936
-
由 Guillaume Gomez 提交于
std: add some missing repr(transparent) For some types we don't want to stably guarantee this, so hide the `repr` from rustdoc. This nice approach was suggested by `@thomcc.`
-
由 Guillaume Gomez 提交于
Add `{Local}ModDefId` to more strongly type DefIds` Based on #110862 by `@Nilstrieb`
-
由 Guillaume Gomez 提交于
Infer `Lld::No` linker hint when the linker stem is a generic compiler driver This PR basically reverts the temporary solution in https://github.com/rust-lang/rust/pull/113631 to a more long-term solution. r? ``@petrochenkov`` In [this comment](https://github.com/rust-lang/rust/pull/113631#issuecomment-1634598238), you had ideas about a long-term solution: > I wonder what a good non-temporary solution for the inference would look like. > > * If the default is `(Cc::No, Lld::Yes)` (e.g. `rust-lld`) > > * and we switch to some specific platform compiler (e.g. `-C linker=arm-none-eabi-gcc`), should we change to `Lld::No`? Maybe yes? > * and we switch to some non-default but generic compiler `-C linker=clang`? Then maybe not? > > * If the default is `(Cc::Yes, Lld::Yes)` (e.g. future x86_64 linux with default LLD) > > * and we switch to some specific platform compiler (e.g. `-C linker=arm-none-eabi-gcc`), should we change to `Lld::No`? Maybe yes? > * and we switch to some non-default but generic compiler `-C linker=clang`? Then maybe not? > I believe that we should infer the `Lld::No` linker hint for any `-Clinker` override, and all the cases above: - the linker drivers have their own defaults, so in my mind `-Clinker` is a signal to use its default linker / flavor, rather than ours or the target's. In the case of generic compilers, it's more likely than not going to be `Lld::No`. I would expect this to be the case in general, even when including platform-specific compilers. - the guess will be wrong if the linker driver uses lld by default (and we also don't want to search for `-fuse-ld` link args), but will work in the more common cases. And the minority of other cases can fix the wrong guess by opting into the precise linker flavor. - this also ensures backwards-compatibility: today, even on targets with an lld default and overriding the linker, rustc will not use lld. That includes `thumbv6m-none-eabi` where issue #113597 happened. It looks like the simplest option, and the one with least churn: we maintain the current behavior in ambiguous cases. I've tested that this works on #113597, as expected from the failure. (I also have a no-std `run-make` test using a custom target json spec: basically simulating a future `x86_64-unknown-linux-gnu` using an lld flavor by default, to check that e.g. `-Clinker=clang` doesn't use lld. I could add that test to this PR, but IIUC such a custom target requires `cargo -Z build-std` and we have no tests depending on this cargo feature yet. Let me know if you want to add this test of the linker inference for such targets.) What do you think ?
-
由 bors 提交于
Use `unstable_target_features` when checking inline assembly This is necessary to properly validate register classes even when the relevant target feature name is still unstable.
-
由 bors 提交于
Switch to LLD as default linker for loongarch64-unknown-none* The [LLD already supports LoongArch](https://github.com/rust-lang/llvm-project/commit/6084ee742064cf8121444febee342133b0cb7abd), it's time to switch to LLD as default linker for `loongarch64-unknown-none*`.
-
由 bors 提交于
Warn on inductive cycle in coherence leading to impls being considered not overlapping This PR implements a `coinductive_overlap_in_coherence` lint (#114040), which warns users against cases where two impls are considered **not** to overlap during coherence due to an inductive cycle disproving one of the predicates after unifying the two impls. Cases where this lint fires will become an overlap error if we ever move to coinduction, so I'd like to make this a warning to avoid having more crates take advantage of this behavior in the mean time. Also, since the new trait solver treats inductive cycles as ambiguity, not an error, this is a blocker for landing the new trait solver in coherence.
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
Co-authored-by: Nlcnr <rust@lcnr.de>
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 bors 提交于
Match scrutinee need necessary parentheses for structs Fixes #113459
-
由 bors 提交于
Couple of global state and driver refactors * Remove some unused global mutable state * Remove a couple of unnecessary queries (both driver and `TyCtxt` queries) * Remove an unnecessary use of `FxIndexMap`
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Meng Xiangzhuo 提交于
-
由 Meng Xiangzhuo 提交于
-
由 Meng Xiangzhuo 提交于
-
由 Meng Xiangzhuo 提交于
-