| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Don't reset cast kind without also updating the operand in `simplify_cast` in GVN
Consider this heavily elided segment of the pre-GVN example code that was committed as a test:
```rust
let _4: *const ();
let _5: *const [()];
let mut _6: *const ();
let _7: *mut ();
let mut _8: *const [()];
let mut _9: std::boxed::Box<()>;
let mut _10: *const ();
/* ... */
// Deref a box
_10 = copy ((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>) as *const () (Transmute);
_4 = copy _10;
_6 = copy _4;
// Inlined body of `slice::from_raw_parts`, to turn a unit pointer into a slice-of-unit pointer
_5 = *const [()] from (copy _6, copy _11);
_8 = copy _5;
// Cast the raw slice-of-unit pointer back to a unit pointer
_7 = copy _8 as *mut () (PtrToPtr);
```
A malformed optimization was changing `_7` (which casted the slice-of-unit ptr to a unit ptr) to:
```
_7 = copy _5 as *mut () (Transmute);
```
...where `_8` was just replaced with `_5` bc of simple copy propagation, that part is not important... the CastKind changing to Transmute is the important part here.
In #133324, two new functionalities were implemented:
* Peeking through unsized -> sized PtrToPtr casts whose operand is `AggregateKind::RawPtr`, to turn it into PtrToPtr casts of the base of the aggregate. In this case, this allows us to see that the value of `_7` is just a ptr-to-ptr cast of `_6`.
* Folding a PtrToPtr cast of an operand which is a Transmute cast into just a single Transmute, which (theoretically) allows us to treat `_7` as a transmute into `*mut ()` of the base of the cast of `_10`, which is the place projection of `((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>)`.
However, when applying those two subsequent optimizations, we must *not* update the CastKind of the final cast *unless* we also update the operand of the cast, since the operand may no longer make sense with the updated CastKind.
In this case, this is problematic because the type of `_8` is `*const [()]`, but that operand in assignment statement of `_7` does *not* get turned into something like `((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>)` -- **in other words, `try_to_operand` fails** -- because GVN only turns value nodes into locals or consts, not projections of locals. So we fail to update the operand, but we still update the CastKind to Transmute, which means we now are transmuting types of different sizes (a wide pointer and a thin pointer).
r? `@scottmcm` or `@cjgillot`
Fixes #136361
Fixes #135997
|
|
disallow `repr()` on invalid items
fixes https://github.com/rust-lang/rust/issues/129606
fixes https://github.com/rust-lang/rust/issues/132391
Disallows `repr()` (so a repr with no arguments) on items where that won't ever make sense.
Also this generates an error when `repr` is used on a trait method and the `fn_align` feature is not enabled. Looks like that was missed here:
https://github.com/rust-lang/rust/pull/110313/files
Which first accepts the align attribute on trait methods.
r? `@compiler-errors`
cc `@jdonszelmann` who claimed https://github.com/rust-lang/rust/issues/132391 and generally has been working on attributes
|
|
|
|
|
|
r=compiler-errors
Fix accidentally not emitting overflowing literals lints anymore in patterns
This was regressed in https://github.com/rust-lang/rust/pull/134228 (not in beta yet).
The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code.
So now I've set it up for visitors to be able to directly visit literals and get all literals
|
|
Use short ty string for binop and unop errors
```
error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)`
--> $DIR/binop.rs:10:7
|
LL | x + x;
| - ^ - (..., ..., ..., ...)
| |
| (..., ..., ..., ...)
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
```
error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)`
--> $DIR/binop.rs:14:5
|
LL | !x;
| ^^ cannot apply unary operator `!`
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
CC #135919.
|
|
Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types
Check for impossible obligations in the `dyn Trait` type we're trying to compute its the vtable upcasting and method call slots.
r? lcnr
|
|
Pretty print pattern type values with transmute if they don't satisfy their pattern
Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`.
These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code.
follow-up to https://github.com/rust-lang/rust/pull/136176
cc ``@compiler-errors`` ``@scottmcm``
r? ``@RalfJung`` because of the interpreter changes
|
|
Always compute coroutine layout for eagerly emitting recursive layout errors
Detect recursive coroutine layouts even if we don't detect opaque type recursion in the new solver. This is for two reasons:
1. It helps us detect (bad) recursive async function calls in the new solver, which due to its approach to normalization causes us to not detect this via a recursive RPIT (since the opaques are more eagerly revealed in the opaque body).
* Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/137.
2. It helps us detect (bad) recursive async functions behind AFITs. See the AFIT test that changed for the old solver too.
3. It also greatly simplifies the recursive impl trait check, since I can remove some jankness around how it handles coroutines.
|
|
Only highlight unmatchable parameters at the definition site
Followup to #136497
This generally results more focused messages in the same vein as #99635 (see `test/ui/argument-suggestions/complex.rs`). There are still some cases (e.g. `test/ui/argument-suggestions/permuted_arguments.rs`) where it might be worth highlighting the arguments. This is mitigated by the fact that a suggestion with a suggested rearrangement is given.
r? `@compiler-errors`
|
|
Fix `rustc_hidden_type_of_opaques` for RPITITs with no default body
Needed this when debugging something
|
|
Pass spans around new solver
...so that when we instantiate canonical responses, we can actually have region obligations with the right span.
Within the solver itself, we still use dummy spans everywhere.
|
|
Avoid using make_direct_deprecated() in extern "ptx-kernel"
This method will be removed in the future as it produces a broken ABI that depends on cg_llvm implementation details. After this PR wasm32-unknown-unknown is the only remaining user of make_direct_deprecated().
Fixes https://github.com/rust-lang/rust/issues/117271
Blocks https://github.com/rust-lang/rust/issues/38788
|
|
|
|
|
|
parameters when showing the definition.
|
|
their pattern
|
|
|
|
|
|
Arbitrary self types v2: recursion test
Add a test for infinite recursion of an arbitrary self type.
These diagnostics aren't perfect (especially the repetition of the statement that there's too much recursion) but for now at least let's add a test to confirm that such diagnostics are emitted.
As suggested by ```@oli-obk```
Relates to #44874
r? ```@wesleywiser```
|
|
Rename and Move some UI tests to more suitable subdirs
## Affected Tests
- tests/ui/issues/issue-48838.rs -> tests/ui/enum/closure-in-enum-issue-48838.rs https://github.com/rust-lang/rust/issues/48838
- tests/ui/issues/issue-40350.rs -> tests/ui/enum/enum-inside-enum-issue-40350.rs https://github.com/rust-lang/rust/issues/40350
- tests/ui/issues/issue-41272.rs -> tests/ui/expr/if/if-let-no-match-guards-issue-41272.rs https://github.com/rust-lang/rust/issues/41272
- tests/ui/issues/issue-40408.rs -> tests/ui/lexer/floating-point-0e10-issue-40408.rs https://github.com/rust-lang/rust/issues/40408
- tests/ui/issues/issue-40136.rs -> tests/ui/macros/const-expr-invocations-issue-40136.rs https://github.com/rust-lang/rust/issues/40136
- tests/ui/issues/issue-40845.rs -> tests/ui/macros/macros-in-trait-positions-issue-40845.rs https://github.com/rust-lang/rust/issues/40845
- tests/ui/issues/issue-41213.rs -> tests/ui/match/enum-and-break-in-match-issue-41213.rs https://github.com/rust-lang/rust/issues/41213
- tests/ui/issues/issue-40782.rs -> tests/ui/suggestions/for-loop-missing-in.rs https://github.com/rust-lang/rust/issues/40782
- tests/ui/issues/issue-40827.rs -> tests/ui/trait-bounds/deep-level-Send-bound-check-issue-40827.rs https://github.com/rust-lang/rust/issues/40827
- tests/ui/issues/issue-40610.rs -> tests/ui/typeck/coercion-check-for-addition-issue-40610.rs https://github.com/rust-lang/rust/issues/40610
- tests/ui/issues/issue-40883.rs -> tests/ui/codegen/StackColoring-not-blowup-stack-issue-40883.rs https://github.com/rust-lang/rust/issues/40883
- tests/ui/issues/issue-40861.rs -> tests/ui/typeck/coercion-check-for-indexing-expression-issue-40861.rs https://github.com/rust-lang/rust/issues/40861
- tests/ui/issues/issue-41139.rs -> tests/ui/typeck/unsized-rvalue-issue-41139.rs https://github.com/rust-lang/rust/issues/41139
- tests/ui/issues/issue-40749.rs -> tests/ui/wf/range-expr-root-of-constant-issue-40749.rs https://github.com/rust-lang/rust/issues/40749
- tests/ui/issues/issue-40235.rs -> tests/ui/while/while-let-scope-issue-40235.rs https://github.com/rust-lang/rust/issues/40235
|
|
implement inherent str constructors
implement #131114
this implements
- str::from_utf8
- str::from_utf8_mut
- str::from_utf8_unchecked
- str::from_utf8_unchecked_mut
i left `std::str::from_raw_parts` and `std::str::from_raw_parts_mut` out of this as those are unstable and were not mentioned by the tracking issue or the original pull request, but i can add those here as well.
i was also unsure of what to do with the `rustc_const_(un)stable` attributes: i removed the `#[rustc_const_stable]` attribute from `str::from_utf8`, `str::from_utf8_unchecked` and `str::from_utf8_unchecked_mut`, and left the`#[rust_const_unstable]` in `str::from_utf8_mut` (btw why is that one not const stable yet with #57349 merged?).
is there a way to redirect users to the stable `std::str::from_utf8` instead of only saying "hey this is unstable"?
for now i just removed the check for `str::from_utf8` in the test in `tests/ui/suggestions/suggest-std-when-using-type.rs`.
|
|
std: move network code into `sys`
As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.
I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
|
|
Reject negative literals for unsigned or char types in pattern ranges and literals
It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic.
In https://github.com/rust-lang/rust/pull/134228 I caused
```rust
fn main() {
match 42_u8 {
-10..255 => {},
_ => {}
}
}
```
to just compile without even a lint.
I can't believe we didn't have tests for this
Amusingly https://github.com/rust-lang/rust/pull/136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.
|
|
Make cenum_impl_drop_cast a hard error
This changes the `cenum_impl_drop_cast` lint to be a hard error. This lint has been deny-by-default and warning in dependencies since https://github.com/rust-lang/rust/pull/97652 about 2.5 years ago.
Closes https://github.com/rust-lang/rust/issues/73333
|
|
tests: Port `split-debuginfo` to rmake.rs
Part of #121876.
This PR supersedes #128754 and is co-authored with `@Oneirical.`
## Known limitations
- In general, like the `Makefile` version, this test in its present form is also somewhat funny because for the most part it merely checks for existence/absence of output artifacts but makes no attempt to actually check if the debuginfo is at all usable.
## Changes
This PR ports `tests/run-make/split-debuginfo` to rmake.rs. This is an **initial** port, and certainly could be cleaned up and/or enhanced.
The original Makefile version had several functional problems. I fixed some of them, but also left some existing issues as-is.
1. The linux/non-linux final branch had a conditional interpolation of `UNSTABLE_OPTIONS := -Zunstable-options`. However, one of the use sites was `-C $(UNSTABLE_OPTIONS) split-debuginfo`. This indicates to me that this run-make test is not run in CI under a non-linux + non-windows + non-darwin environment, because that would've failed as this would expand to `-C -Zunstable-options split-debuginfo`. I fixed this in the rmake.rs version, but I'm not sure if this distinction is worth keeping at all if it's not tested in CI.
2. There are several comments that were discovered to be wrong. I tried to fix them in the rmake.rs version as well.
3. The check for path remapping / lack of path remapping through
```make
objdump -Wi $(TMPDIR)/foo | grep DW_AT_GNU_dwo_name | (! grep $(TMPDIR)) || exit 1
```
is incorrect, because that looks at the single line of that contains `DW_AT_GNU_dwo_name`. This is unfortunately wrong because empirical evidence shows that with `objdump`[^objdump], the check actually needs to look at the attribute value of `DW_AT_comp_dir` on the previous line not `DW_AT_GNU_dwo_name`[^gnu-ext]. Example output of `objdump`:
```text
<10> DW_AT_comp_dir : (indirect string, offset: 0xafb48): /home/joe/repos/rust
<14> DW_AT_GNU_dwo_name: (indirect string, offset: 0x5d1b0): foo.foo.fc848df41df7a00d-cgu.0.rcgu.dwo
```
In the rmake.rs version I used a 2-line sliding window to check for `DW_AT_comp_dir` and `DW_AT_GNU_dwo_name`, but to look at `DW_AT_comp_dir` specifically.
4. I included a bunch of FIXMEs and ENHANCEMENTs I noticed regarding the test because I didn't want to fix them in this initial port[^enhancement].
5. The Makefile version didn't test *anything* on Windows (both windows-msvc and windows-gnu). I added some *very* basic and *very* sparse checks for windows-msvc, but I am not willing to spend the effort to expand test coverage to windows-gnu in this initial port.
6. This run-make test is way too big. But I didn't want to expend the effort of breaking this up in this initial port.
[^objdump]: the output format differs between `objdump` and `llvm-objdump`, but the same is true for `llvm-objdump` that this is looking at the wrong line.
[^gnu-ext]: AFAICT that is a GNU DWARF attribute extension, since it isn't mentioned in DWARFv5 spec
[^enhancement]: For instance, the previous path remapping check could in theory be precisely inspected by inspecting `.debug_info` section to look for attribute value of `DW_AT_comp_dir`. But that involves resolving the value of the indirect string, which means you have to: (1) look for offset into string offset table and (2) use *that* offset to find the string itself in the string table. The split part of "split-debuginfo" makes this murky for me, so I wasn't able to replace `llvm-objdump` textual output substring matches with more precise `object` + `gimli` inspections.
## Review advice
- I'm sorry for how long the rmake.rs test ended up, but a lot of it is comments and just vertical space due to formatting. If there's any ways to make this test less long / convoluted, advice would be appreciated.
- This PR *intentionally* introduces several intermediate commits for the `Makefile`, mostly to illustrate the problems I discovered when looking at the original `Makefile` version. This is intended to highlight the existing problems in the `Makefile` version for the reviewer[^squash].
- There are several intentional non-functional commits:
1. Reindent the `Makefile` to make the platform conditional gating more obvious.
2. Collapse nested if-else branches into an else if construct, which is not supported by GNU Make 3.80.
3. Remove all redundant `-C debuginfo=2` when `-g` is already specified.
- This PR is best reviewed commit-by-commit.
[^squash]: I intend to squash these intermediate commits away after the reviewer concludes that the current form of the rmake.rs test is acceptable for merge. Before then, I'll keep them to help with review.
---
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
|
|
|
|
|
|
Add a test for infinite recursion of an arbitrary self type.
These diagnostics aren't perfect (especially the repetition of the
statement that there's too much recursion) but for now at least
let's add a test to confirm that such diagnostics are emitted.
|
|
Add tests for nested macro_rules edition behavior
This adds tests to check the behavior of how nested macro_rules definitions work across edition boundaries. This covers a change in behavior due to https://github.com/rust-lang/rust/pull/133274.
See https://github.com/rust-lang/rust/issues/135669
|
|
#[contracts::requires(...)] + #[contracts::ensures(...)]
cc https://github.com/rust-lang/rust/issues/128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition, building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).
Known issues:
* My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called `contracts::requires`.
* Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
* (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)
* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
|
|
Rollup of 7 pull requests
Successful merges:
- #136242 (Remove `LateContext::match_def_path()`)
- #136274 (Check Sizedness of return type in WF)
- #136284 (Allow using named consts in pattern types)
- #136477 (Fix a couple NLL TLS spans )
- #136497 (Report generic mismatches when calling bodyless trait functions)
- #136520 (Remove unnecessary layout assertions for object-safe receivers)
- #136526 (mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`)
Failed merges:
- #136304 (Reject negative literals for unsigned or char types in pattern ranges and literals)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Remove unnecessary layout assertions for object-safe receivers
The soundness of `DispatchFromDyn` relies on the fact that, like all other built-in marker-like layout traits (e.g. `Sized`, `CoerceUnsized`), the guarantees that they enforce in *generic* code via traits will result in assumptions that we can rely on in codegen.
Specifically, `DispatchFromDyn` ensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds the `Scalar` or `ScalarPair` representation for sized and unsized pointees, respectively.
The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best.
This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161b1bbe6234188d6cfb3cabddef1e6ef20f.
Fixes #125810
Fixes #90110
This PR is an alternative to #136195. cc `@adetaylor.` I didn't realize in that PR that the layout checks that were being modified were simply *sanity checks*, rather than being actually necessary for soundness.
|
|
Report generic mismatches when calling bodyless trait functions
Don't know if there's an open issue for this. Just happened to notice this when working in that area.
The awkward extra spans added to the diagnostics of some tests (e.g. `trait-with-missing-associated-type-restriction`) is consistent with what happens for normal functions. Should probably be removed since that span doesn't seem to note anything useful.
First and third commit are both cleanups removing some unnecessary work. Second commit has the actual fix.
fixes #135124
|
|
Fix a couple NLL TLS spans
Some NLL TLS tests show incorrect spans for the end of function. It seems that the `TerminatorKind::Return` source info span can sometimes point at the single character after the end of the function.
Completely changing the span where the terminator is built also changes a bunch of diagnostics: small functions have more code shown unrelated to the errors at hand, wrapping symbols appear and weird-looking arrows point to the end of function, etc. So it seems this is somehow unexpectedly relied upon in making diagnostics look better and their heuristics.
So I just changed it where it matters for these few tests: the diagnostics specialized to conflict errors with thread locals.
r? `@matthewjasper`
|
|
Allow using named consts in pattern types
This required a refactoring first: I had to stop using `hir::Pat`in `hir::TyKind::Pat` and instead create a separate `TyPat` that has `ConstArg` for range ends instead of `PatExpr`. Within the type system we should be using `ConstArg` for all constants, as otherwise we'd be maintaining two separate const systems that could diverge. The big advantage of this PR is that we now inherit all the rules from const generics and don't have a separate system. While this makes things harder for users (const generic rules wrt what is allowed in those consts), it also means we don't accidentally allow some things like referring to assoc consts or doing math on generic consts.
|
|
Check Sizedness of return type in WF
Still need to clean this up a bit. This should fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/150.
r? lcnr
|
|
Add `unchecked_disjoint_bitor` per ACP373
Following the names from libs-api in https://github.com/rust-lang/libs-team/issues/373#issuecomment-2085686057
Includes a fallback implementation so this doesn't have to update cg_clif or cg_gcc, and overrides it in cg_llvm to use `or disjoint`, which [is available in LLVM 18](https://releases.llvm.org/18.1.0/docs/LangRef.html#or-instruction) so hopefully we don't need any version checks.
|
|
tests/ui/match/enum-and-break-in-match-issue-41213.rs
and tests/ui/while/while-let-scope-issue-40235.rs doesn't
need to be run.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #136398 (add UnsafeCell direct access APIs)
- #136465 (Some `rustc_middle` cleanups)
- #136479 (std::fs: further simplify dirent64 handling)
- #136504 (Fix last compare-mode false negatives in tests)
- #136511 (Add `cast_signed` and `cast_unsigned` methods for `NonZero` types)
- #136518 (Add note about `FnPtr` trait being exposed as public bound)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fix last compare-mode false negatives in tests
This PR is a continuation of #136310 and fixes the last remaining cases of false negatives when running tests under a compare-mode.
With these normalizations, all the compare-mode failures in `next-solver` (and `polonius`) should now be real, actual differences in diagnostics.
|
|
Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
|
|
Enable more tests on Windows
As part of the discussion of https://github.com/rust-lang/compiler-team/issues/822 on Zulip, it was mentioned that problems with the i686-pc-windows-gnu target may have resulted in tests being disabled on Windows.
So in this PR, I've ripped out all our `//@ ignore-windows` directives, then re-added all the ones that are definitely required based on the outcome of try-builds, and in some cases I've improved the justification or tightened the directives to `//@ ignore-msvc` or ignoring specific targets.
|
|
Rollup of 6 pull requests
Successful merges:
- #134807 (fix(rustdoc): always use a channel when linking to doc.rust-lang.org)
- #134814 (Add `kl` and `widekl` target features, and the feature gate)
- #135836 (bootstrap: only build `crt{begin,end}.o` when compiling to MUSL)
- #136022 (Port ui/simd tests to use the intrinsic macro)
- #136309 (set rustc dylib on manually constructed rustc command)
- #136462 (mir_build: Simplify `lower_pattern_range_endpoint`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Port ui/simd tests to use the intrinsic macro
|
|
Add `kl` and `widekl` target features, and the feature gate
This is an effort towards #134813. This PR adds the target-features and the feature gate to `rustc`
<!--
```@rustbot``` label O-x86_64 O-x86_32 A-target-feature
r? compiler
-->
|
