Rollup of 7 pull requests
Successful merges:
- #87107 (Loop over all opaque types instead of looking at just the first one with the same DefId)
- #87158 (Suggest full enum variant for local modules)
- #87174 (Stabilize `[T; N]::map()`)
- #87179 (Mark `const_trait_impl` as active)
- #87180 (feat(rustdoc): open sidebar menu when links inside it are focused)
- #87188 (Add GUI test for auto-hide-trait-implementations setting)
- #87200 (TAIT: Infer all inference variables in opaque type substitutions via InferCx)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
TAIT: Infer all inference variables in opaque type substitutions via InferCx
The previous algorithm was correct for the example given in its
documentation, but when the TAIT was declared as a free item
instead of an associated item, the generic parameters were the
wrong ones.
cc `@spastorino`
r? `@nikomatsakis`
Loop over all opaque types instead of looking at just the first one with the same DefId
This exposed a bug in VecMap and is needed for https://github.com/rust-lang/rust/pull/86410 anyway
r? ``@spastorino``
cc ``@nikomatsakis``
The previous algorithm was correct for the example given in its
documentation, but when the TAIT was declared as a free item
instead of an associated item, the generic parameters were the
wrong ones.
Remove refs from Pat slices
Changes `PatKind::Or(&'hir [&'hir Pat<'hir>])` to `PatKind::Or(&'hir [Pat<'hir>])` and others. This is more consistent with `ExprKind`, saves a little memory, and is a little easier to use.
RFC2229: Use the correct place type
Closes https://github.com/rust-lang/rust/issues/87097
The ICE occurred because instead of looking at the type of the place after all the projections are applied, we instead looked at the `base_ty` of the Place to decide whether a discriminant should be read of not. This lead to two issues:
1. the kind of the type is not necessarily `Adt` since we only look at the `base_ty`, it could be instead `Ref` for example
2. if the kind of the type is `Adt` you could still be looking at the wrong variant to make a decision on whether the discriminant should be read or not
r? `@nikomatsakis`
Replace associated item bound vars with placeholders when projecting
Fixes#76407Fixes#76826
Similar, but more limited, to #85499. This allows us to handle things like `for<'a> <T as Trait>::Assoc<'a>` but not `for<'a> <T as Trait<'a>>::Assoc`, unblocking GATs.
r? `@nikomatsakis`
Add -Zfuture-incompat-test to assist with testing future-incompat reports.
This adds a `-Zfuture-incompat-test` cli flag to assist with testing future-incompatible reports. This flag causes all lints to be treated as a future-incompatible lint, and will emit a report for them. This is being added so that Cargo's testsuite can reliably test the reporting infrastructure. Right now, Cargo relies on using array_into_iter as a test subject. Since the breaking "future incompatible" lints are never intended to last forever, this means Cargo's testsuite would always need to keep changing to choose different lints (for example, #86330 proposed dropping that moniker for array_into_iter). With this flag, Cargo's tests can trigger any lint and check for the report.
Reuse CrateNum for proc-macro crates even when cross-compiling
Proc-macros are always compiled for the host, so this should be the same
in every way as recompiling the crate.
I am not sure why the previous code special-cased the target, since the
compiler properly gives an error when trying to load a crate for a
different host:
```
error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu
--> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2
|
LL | dependency::is_64();
| ^^^^^^^^^^
|
= note: the following crate versions were found:
crate `dependency`, target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so
```
I think another possible fix is to remove the check altogether. But I'm
not sure, and this fix works, so I'm not making the larger change here.
Fixes https://github.com/rust-lang/rust/issues/56935.
r? `@petrochenkov` cc `@alexcrichton`
Proc-macros are always compiled for the host, so this should be the same
in every way as recompiling the crate.
I am not sure why the previous code special-cased the target, since the
compiler properly gives an error when trying to load a crate for a
different host:
```
error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu
--> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2
|
LL | dependency::is_64();
| ^^^^^^^^^^
|
= note: the following crate versions were found:
crate `dependency`, target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so
```
I think another possible fix is to remove the check altogether. But I'm
not sure, and this fix works, so I'm not making the larger change here.
expand: Support helper attributes for built-in derive macros
This is needed for https://github.com/rust-lang/rust/pull/86735 (derive macro `Default` should have a helper attribute `default`).
With this PR we can specify helper attributes for built-in derives using syntax `#[rustc_builtin_macro(MacroName, attributes(attr1, attr2, ...))]` which mirrors equivalent syntax for proc macros `#[proc_macro_derive(MacroName, attributes(attr1, attr2, ...))]`.
Otherwise expansion infra was already ready for this.
The attribute parsing code is shared between proc macro derives and built-in macros (`fn parse_macro_name_and_helper_attrs`).
This resolves all the problems we had around "normalizing" the representation of a Scalar in case it carries a Pointer value: we can just use Pointer if we want to have a value taht we are sure is already normalized.
Handle non-integer const generic parameters in debuginfo type names.
This PR fixes an ICE introduced by https://github.com/rust-lang/rust/pull/85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits.
The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value.
The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully.
I'd be interested in ideas on how to do this better.
r? `@wesleywiser`
cc `@dpaoliello` (do you see any problems with this approach?)
cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?)
Fixes https://github.com/rust-lang/rust/issues/86893
Rollup of 6 pull requests
Successful merges:
- #87085 (Search result colors)
- #87090 (Make BTreeSet::split_off name elements like other set methods do)
- #87098 (Unignore some pretty printing tests)
- #87099 (Upgrade `cc` crate to 1.0.69)
- #87101 (Suggest a path separator if a stray colon is found in a match arm)
- #87102 (Add GUI test for "go to first" feature)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
When building with profile-generate request that metadata is kept
during the gc_sections call, as this can sometimes strip out profile
data.
This missing information in the prof files can then result in missing
functions when using the profile information.
Avoid cloning ExpnData to access Span edition
ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.
r? `@ghost` -- opening for a perf run to start with
Fix internal `default_hash_types` lint to use resolved path
I run into false positives now and then (mostly in Clippy) when I want to name some util after HashMap.
ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.
target abi
Implement cfg(target_abi) (RFC 2992)
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
Update targets to use `target_abi`
All eabi targets have `target_abi = "eabi".`
All eabihf targets have `target_abi = "eabihf"`.
`armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`.
All abi64 targets have `target_abi = "abi64"`.
All ilp32 targets have `target_abi = "ilp32"`.
All softfloat targets have `target_abi = "softfloat"`.
All *-uwp-windows-* targets have `target_abi = "uwp"`.
All spe targets have `target_abi = "spe"`.
All macabi targets have `target_abi = "macabi"`.
aarch64-apple-ios-sim has `target_abi = "sim"`.
`x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`.
`x86_64-unknown-linux-gnux32` has `target_abi = "x32"`.
Add FIXME entries for targets for which existing values need to change
once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.)
Add a test for `target_abi` in `--print cfg`.
Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck
Since nobody has so far claimed Mutation- and BorrowOfLayoutConstrainedField in rust-lang/project-thir-unsafeck#7, I have taken the liberty of implementing them in thir-unsafeck.
r? `@LeSeulArtichaut`
CTFE engine: small cleanups
I noticed these while preparing a large PR, and figured I'd better send them ahead to not muddy the diff unnecessarily.
- remove remaining use of Pointer in Allocation API (I missed those in https://github.com/rust-lang/rust/pull/85472)
- remove unnecessary deallocate_local hack (this logic does not seem necessary any more)
r? `@oli-obk`
Simplify future incompatible reporting.
This simplifies the implementation of the future incompatible reporting system. Instead of having a separate field in the future_incompatible definition, this reuses the `FutureIncompatibilityReason` enum. It also drops the "date" field. Cargo does not use the date field, and there isn't much of a need for this to be structured, and I am skeptical that the date can be predicted reliably. The date or release version can be listed in the lint text if desired.
Fix ICE with unsized type in const pattern
Fixes#87046. The `deref_const()` query currently contains the following check:
e9a387d6cf/compiler/rustc_mir/src/const_eval/mod.rs (L191-L204)
i.e. this will cause an ICE for every unsized type except slices. An error is reported with my changes if such a type is used as a const pattern (this should not be a breaking change, since so far, this has caused an ICE).
Improve error reporting for modifications behind `&` references
I had a look at #84210 and noticed that #85823 has effectively already fixed#84210.
However, the string matching in #85823 is _very_ crude and already breaks down when a variable name starts with `mut`. I have made this a bit more robust; further improvements could definitely be made but are complicated by the lack of information provided by an earlier pass:
ce331ee6ee/compiler/rustc_mir_build/src/build/matches/mod.rs (L2103-L2107)
I have also fixed a missing comma in the error message.
Report an error if resolution of closure call functions failed
This pull request fixes#86238. The current implementation seems to assume that resolution of closure call functions (I'm not sure what the proper term is; I mean `call` of `Fn` etc.) can never fail:
60f1a2fc4b/compiler/rustc_typeck/src/check/callee.rs (L590-L595)
But actually, it can, if the `fn`/`fn_mut`/`fn_once` lang items are not defined, or don't have an associated `call`/`call_mut`/`call_once` function, leading to the ICE described in #86238. I have therefore turned the `span_bug!()` into an error message, which prevents the ICE.
Do not suggest adding a semicolon after `?`
Fixes#87051. I have only modified `report_return_mismatched_types()`, i.e. my changes only affect suggestions to add `;` for return type mismatches, but this never makes sense after `?`, because the function cannot return `()` if `?` is used (it has to return a `Result` or an `Option`), and a semicolon won't help if the expected and actual `Err` types differ, even if the expected one is `()`.
Stabilize "RangeFrom" patterns in 1.55
Implements a partial stabilization of #67264 and #37854.
Reference PR: https://github.com/rust-lang/reference/pull/900
# Stabilization Report
This stabilizes the `X..` pattern, shown as such, offering an exhaustive match for unsigned integers:
```rust
match x as u32 {
0 => println!("zero!"),
1.. => println!("positive number!"),
}
```
Currently if a Rust author wants to write such a match on an integer, they must use `1..={integer}::MAX` . By allowing a "RangeFrom" style pattern, this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match, allowing for easier refactoring. This is particularly useful for instances like the above case, where different behavior on "0" vs. "1 or any positive number" is desired, and the actual MAX is unimportant.
Notably, this excepts slice patterns which include half-open ranges from stabilization, as the wisdom of those is still subject to some debate.
## Practical Applications
Instances of this specific usage have appeared in the compiler:
16143d1067/compiler/rustc_middle/src/ty/inhabitedness/mod.rs (L219)673d0db5e3/compiler/rustc_ty_utils/src/ty.rs (L524)
And I have noticed there are also a handful of "in the wild" users who have deployed it to similar effect, especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match, as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](05e5db00d5/WebAssembly/scale_std/src/fixed_point.rs (L685-L695)).
## Tests
There were already many tests in [src/test/ui/half-open-range/patterns](90a2e5e3fe/src/test/ui/half-open-range-patterns), as well as [generic pattern tests that test the `exclusive_range_pattern` feature](673d0db5e3/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs), many dating back to the feature's introduction and remaining standing to this day. However, this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is, at least, a mild diagnostic improvement in some edge cases, because before now, the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag, while also emitting the "inclusive range with no end" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of, so removing the flag request is a strict improvement. The arrival of the `J | K` "or" pattern also enables some odd formations.
Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example, linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692, which may be useful to reference to observe the current behavior more closely.
In addition tests constituting an explanation of the "slicing range patterns" syntax issue are included in this PR.
## Desiderata
The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors, as they make some patterns much more natural to write, but there is disagreement regarding the "closed" exclusive range pattern or the "RangeTo" pattern, especially where it creates "off by one" gaps in the presence of a "catch-all" wildcard case. Also, there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on, ideally, and I think it would be reasonable to consider such a blocker to stabilizing this feature, but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the "point" of the feature, at least from my view, is to make it easier to omit wildcard matches: a pattern with such an "open" match produces an irrefutable match and does not need the wild card case, making it easier to benefit from exhaustiveness checking.
## History
- Implemented:
- Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712
- Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258
- Unresolved Questions:
- The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles, given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656, but it is still unknown what changes might be desired
- How we want to handle slice patterns in ranges seems to be an open question still, as witnessed in the discussion of this PR!
I checked but I couldn't actually find an RFC for this, and given "approved provisionally by lang team without an RFC", I believe this might require an RFC before it can land? Unsure of procedure here, on account of this being stabilizing a subset of a feature of syntax.
r? `@scottmcm`
Improves migrations lint for RFC2229
This PR improves the current disjoint capture migration lint by providing more information on why drop order or auto trait implementation for a closure is impacted by the use of the new feature.
The drop order migration lint will now look something like this:
```
error: changes to closure capture in Rust 2021 will affect drop order
--> $DIR/significant_drop.rs:163:21
|
LL | let c = || {
| ^^
...
LL | tuple.0;
| ------- in Rust 2018, closure captures all of `tuple`, but in Rust 2021, it only captures `tuple.0`
...
LL | }
| - in Rust 2018, `tuple` would be dropped here, but in Rust 2021, only `tuple.0` would be dropped here alongside the closure
```
The auto trait migration lint will now look something like this:
```
error: changes to closure capture in Rust 2021 will affect `Send` trait implementation for closure
--> $DIR/auto_traits.rs:14:19
|
LL | thread::spawn(move || unsafe {
| ^^^^^^^^^^^^^^ in Rust 2018, this closure would implement `Send` as `fptr` implements `Send`, but in Rust 2021, this closure would no longer implement `Send` as `fptr.0` does not implement `Send`
...
LL | *fptr.0 = 20;
| ------- in Rust 2018, closure captures all of `fptr`, but in Rust 2021, it only captures `fptr.0`
```
r? `@nikomatsakis`
Closes https://github.com/rust-lang/project-rfc-2229/issues/54
Add clobber-only register classes for asm!
These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
- The `Rustc::expn_id` field kept redundant information
- `SyntaxContext` is no longer thrown away before `save_proc_macro_span` because it's thrown away during metadata encoding anyway
Improve opaque pointers support
Opaque pointers are coming, and rustc is not ready.
This adds partial support by passing an explicit load type to LLVM. Two issues I've encountered:
* The necessary type was not available at the point where non-temporal copies were generated. I've pushed the code for that upwards out of the memcpy implementation and moved the position of a cast to make do with the types we have available. (I'm not sure that cast is needed at all, but have retained it in the interest of conservativeness.)
* The `PlaceRef::project_deref()` function used during debuginfo generation seems to be buggy in some way -- though I haven't figured out specifically what it does wrong. Replacing it with `load_operand().deref()` did the trick, but I don't really know what I'm doing here.
remove const_raw_ptr_to_usize_cast feature
This feature currently has the strange status of "const-only `unsafe`", which was an experiment that we no longer think is a good idea. We need to find better ways to enable things like "messing with the low bits of a pointer" during CTFE.
r? `@oli-obk`
Fix several ICEs related to malformed `#[repr(...)]` attributes
This PR fixes#83921. #83921 actually contains two related but distinct issues (one of them incorrectly reported as a duplicate in https://github.com/rust-lang/rust/issues/83921#issuecomment-814640734):
In the first, a call to `delay_span_bug` leads to an ICE when compiling with `-Zunpretty=everybody_loops` (and some other pretty-printing modes), because the corresponding error is emitted in a later pass, which does not run when only pretty-printing is requested.
The second issue is about parsing `#[repr(...)]` attributes. Currently, all of the following cause an ICE when applied to a struct/enum:
```rust
#[repr(packed())]
#[repr(align)]
#[repr(align(2, 4))]
#[repr(align())]
#[repr(i8())]
#[repr(u32(42))]
#[repr(i64 = 2)]
```
I have fixed this by expanding the well-formedness checks in `find_repr_attrs()`.
Revert the revert of renaming traits::VTable to ImplSource
As #72114 and #73055 were merged so closely together I think this
accidentally happened while rebasing
These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
Support forwarding caller location through trait object method call
Since PR #69251, the `#[track_caller]` attribute has been supported on
traits. However, it only has an effect on direct (monomorphized) method
calls. Calling a `#[track_caller]` method on a trait object will *not*
propagate caller location information - instead, `Location::caller()` will
return the location of the method definition.
This PR forwards caller location information when `#[track_caller]` is
present on the method definition in the trait. This is possible because
`#[track_caller]` in this position is 'inherited' by any impls of that
trait, so all implementations will have the same ABI.
This PR does *not* change the behavior in the case where
`#[track_caller]` is present only on the impl of a trait.
While all implementations of the method might have an explicit
`#[track_caller]`, we cannot know this at codegen time, since other
crates may have impls of the trait. Therefore, we keep the current
behavior of not forwarding the caller location, ensuring that all
implementations of the trait will have the correct ABI.
See the modified test for examples of how this works
If crate declares `rust_eh_personality`, re-use existing declaration
as otherwise attempts to set function attributes that follow the
declaration will fail (unless it happens to have exactly the same
type signature as the one predefined in the compiler).
only check cg defaults wf once instantiated
the previous fixmes here didn't make too much sense as I didn't yet fully understand the code further below.
That code only runs if the predicates using our generic param default are fully concrete after substituting our default, which never happens if our default is generic.
r? `@oli-obk` `@BoxyUwU`
Remove `missing_docs` lint on private 2.0 macros
798baebde1/compiler/rustc_lint/src/builtin.rs (L573-L584)
This code is the source of #57569. The problem is subtle, so let me point it out. This code makes the mistake of assuming that all of the macros in `krate.exported_macros` are exported.
...Yeah. For some historical reason, all `macro` macros are marked as exported, regardless of whether they actually are, which is dreadfully confusing. It would be more accurate to say that `exported_macros` currently contains only macros that have paths.
This PR renames `exported_macros` to `importable_macros`, since these macros can be imported with `use` while others cannot. It also fixes the code above to no longer lint on private `macro` macros, since the `missing_docs` lint should only appear on exported items.
Fixes#57569.
Add support for raw-dylib with stdcall, fastcall functions
Next stage of work for #58713: allow `extern "stdcall"` and `extern "fastcall"` with `#[link(kind = "raw-dylib")]`.
I've deliberately omitted support for vectorcall, as that doesn't currently work, and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet, but at first (very cursory) glance it appears that the problem is elsewhere.)
Simply shift the bitcast from the store to the load, so that
we can use the destination type. I'm not sure the bitcast is
really necessary, but keeping it for now.
I'm not really sure what is wrong here, but I was getting load
type mismatches in the debuginfo code (which is the only place
using this function).
Replacing the project_deref() implementation with a generic
load_operand + deref did the trick.
This makes load generation compatible with opaque pointers.
The generation of nontemporal copies still accesses the pointer
element type, as fixing this requires more movement.
Use #[track_caller] in const panic diagnostics.
This change stops const panic diagnostics from reporting inside #[track_caller] functions by skipping over them.
Change linked tracking issue for more_qualified_paths
This updates the linked tracking issue for the `more_qualified_paths` feature from the implementation PR #80080 to an actual tracking issue #86935.
Fix double warning about illegal floating-point literal pattern
This PR fixes#86600. The problem is that the `ConstToPat` struct contains a field `include_lint_checks`, which determines whether lints should be emitted or not, but this field is currently not obeyed at one point, leading to a warning being emitted more than once. I have fixed this behavior here.
Account for capture kind in auto traits migration
Modifies the current auto traits migration for RFC2229 so it takes into account capture kind
Closes https://github.com/rust-lang/project-rfc-2229/issues/51
r? `@nikomatsakis`
2229: Reduce the size of closures with `capture_disjoint_fields`
One key observation while going over the closure size profile of rustc
was that we are disjointly capturing one or more fields starting at an
immutable reference.
Disjoint capture over immutable reference doesn't add too much value
because the fields can either be borrowed immutably or copied.
One possible edge case of the optimization is when a fields of a struct
have a longer lifetime than the structure, therefore we can't completely
get rid of all the accesses on top of sharef refs, only the rightmost
one. Here is a possible example:
```rust
struct MyStruct<'a> {
a: &'static A,
b: B,
c: C<'a>,
}
fn foo<'a, 'b>(m: &'a MyStruct<'b>) -> impl FnMut() + 'static {
let c = || drop(&*m.a.field_of_a);
// Here we really do want to capture `*m.a` because that outlives `'static`
// If we capture `m`, then the closure no longer outlives `'static'
// it is constrained to `'a`
}
```
r? `@nikomatsakis`
- Add `:Sized` assertion in interpreter impl
- Use `Scalar::from_bool` instead of `ScalarInt: From<bool>`
- Remove unneeded comparison in intrinsic typeck
- Make this UB to call with undef, not just return undef in that case
LLVM target name does not necessarily match the Rust target name and it
can be confusing when the ICE message is describing a target other than
has been specified on the command line.
Checking that function is const if marked with rustc_const_unstable
Fixes#69630
This one is still missing tests to check the behavior but I checked by hand and it seemed to work.
I would not mind some direction for writing those unit tests!
Use diagnostic items instead of lang items for rfc2229 migrations
This PR removes the `Send`, `UnwindSafe` and `RefUnwindSafe` lang items introduced in https://github.com/rust-lang/rust/pull/84730, and uses diagnostic items instead to check for `Send`, `UnwindSafe` and `RefUnwindSafe` traits for RFC2229 migrations.
r? ```@nikomatsakis```
remove trailing newline
fix: test with attribute but missing const
Update compiler/rustc_passes/src/stability.rs
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
Add test for extern functions
fix: using span_help instead of span_suggestion
add test for some ABIs + fmt fix
Update compiler/rustc_passes/src/stability.rs
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
Refractor and add test for `impl const`
Add test to make sure no output + cleanup condition
-----------------------------
remove stdcall test, failing CI test
C abi is already tested in this, so it is not that useful to test another one.
The tested code is blind to which specific ABI for now, as long as it's not an intrinsic one
Fix ICE when misplaced visibility cannot be properly parsed
Fixes#86895
The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted.
The resulting error isn't quite as nice as when the visibility is parsed properly, but I'm not sure which error to prioritize here. Displaying both errors might be too confusing.
r? ```@estebank```
Sync rustc_codegen_cranelift
The main hightlight this sync is basic support for AArch64. Most things should work on Linux, but there does seem to be an ABI incompatibility causing proc-macros to crash, see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166)
r? ```@ghost```
```@rustbot``` label +A-codegen +A-cranelift +T-compiler
Recover from `&dyn mut ...` parse errors
Consider this example:
```rust
fn main() {
let r: &dyn mut Trait;
}
```
This currently leads to:
```
error: expected one of `!`, `(`, `;`, `=`, `?`, `for`, lifetime, or path, found keyword `mut`
--> src/main.rs:2:17
|
2 | let r: &dyn mut Trait;
| ^^^ expected one of 8 possible tokens
error: aborting due to previous error
```
However, especially for beginners, I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes, I get a help message, and the parser even recovers:
```
error: `mut` must precede `dyn`
--> test.rs:2:12
|
2 | let r: &dyn mut Trait;
| ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn`
error[E0405]: cannot find trait `Trait` in this scope
--> test.rs:2:21
|
2 | let r: &dyn mut Trait;
| ^^^^^ not found in this scope
error: aborting due to 2 previous errors
```
Support lint tool names in rustc command line options
When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.
Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034.
Fixes#86628.
This change merges `check_lint_and_tool_name` into `check_lint_name` in
order to avoid having two very similar functions.
Also adds the `.stderr` file back for the test case, since apparently
it is still needed.
All eabi targets have target_abi = "eabi".
All eabihf targets have target_abi = "eabihf".
armv6_unknown_freebsd and armv7_unknown_freebsd have target_abi = "eabihf".
All abi64 targets have target_abi = "abi64".
All ilp32 targets have target_abi = "ilp32".
All softfloat targets have target_abi = "softfloat".
All *-uwp-windows-* targets have target_abi = "uwp".
All spe targets have target_abi = "spe".
All macabi targets have target_abi = "macabi".
aarch64-apple-ios-sim has target_abi = "sim".
x86_64-fortanix-unknown-sgx has target_abi = "fortanix".
x86_64-unknown-linux-gnux32 has target_abi = "x32".
Add FIXME entries for targets for which existing values need to change
once cfg_target_abi becomes stable. (All of them are tier 3 targets.)
Add a test for target_abi in `--print cfg`.
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
This does not add an abi to any existing target.
Rename some Rust 2021 lints to better names
Based on conversation in https://github.com/rust-lang/rust/issues/85894.
Rename a bunch of Rust 2021 related lints:
Lints that are officially renamed because they are already in beta or stable:
* `disjoint_capture_migration` => `rust_2021_incompatible_closure_captures`
* `or_patterns_back_compat` => `rust_2021_incompatible_or_patterns`
* `non_fmt_panic` => `non_fmt_panics`
Lints that are renamed but don't require any back -compat work since they aren't yet in stable:
* `future_prelude_collision` => `rust_2021_prelude_collisions`
* `reserved_prefix` => `rust_2021_token_prefixes`
Lints that have been discussed but that I did not rename:
* ~`non_fmt_panic` and `bare_trait_object`: is making this plural worth the headache we might cause users?~
* `array_into_iter`: I'm unsure of a good name and whether bothering users with a name change is worth it.
r? `@nikomatsakis`
Refactor linker code
This merges `LinkerInfo` into `CrateInfo` as there is no reason to keep them separate. `LinkerInfo::to_linker` is merged into `get_linker` as both have different logic for each linker type and `to_linker` is directly called after `get_linker`. Also contains a couple of small cleanups.
See the individual commits for all changes.
The `large_assignments` lints detects moves over specified limit. The
limit is configured through `move_size_limit = "N"` attribute placed at
the root of a crate. When attribute is absent, the lint is disabled.
Make it possible to enable the lint without making any changes to the
source code, through a new flag `-Zmove-size-limit=N`. For example, to
detect moves exceeding 1023 bytes in a cargo crate, including all
dependencies one could use:
```
$ env RUSTFLAGS=-Zmove-size-limit=1024 cargo build -vv
```
Replace per-target ABI denylist with an allowlist
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
In this PR we got rid of the per-target ABI denylists, and instead compute
which ABIs are supported with a simple match based on, mostly, the
`Target::arch` field. Among other things, this makes it impossible to
forget to consider this problem (in either direction) and forces one to
consider what the ABI support looks like when adding an ABI (rarely)
rather than target (often), which should hopefully also reduce the
cognitive load on both contributors as well as reviewers.
Fixes#57182
Sponsored by: standard.ai
---
## Summary for teams
One significant user-facing change after this PR is that there's now a future compat warning when building…
* `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*;
* `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*.
Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another.
The intention is that this warning becomes a hard error after some time.
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
Fixes#57182
Sponsored by: standard.ai
Query-ify global limit attribute handling
Currently, we read various 'global limits' from inner attributes the crate root (`recursion_limit`, `move_size_limit`, `type_length_limit`, `const_eval_limit`). These limits are then stored in `Sessions`, allowing them to be access from a `TyCtxt` without registering a dependency on the crate root attributes.
This PR moves the calculation of these global limits behind queries, so that we properly track dependencies on crate root attributes. During the setup of macro expansion (before we've created a `TyCtxt`), we need to access the recursion limit, which is now done by directly calling into the code shared by the normal query implementations.
E0716: clarify that equivalent code example is erroneous
In E0716, there is a code block that is equivalent to the erroneous
code example. Especially when viewed with `rustc --explain`, it's
not obvious that it is also erroneous, and some users have been
confused when they try to change their code to match the erroneous
equivalent.
`@rustbot` label +A-diagnostics +D-newcomer-roadblock +T-compiler
Hack: Ignore inference variables in certain queries
Fixes#84841Fixes#86753
Some queries are not built to accept types with inference variables, which can lead to ICEs. These queries probably ought to be converted to canonical form, but as a quick workaround, we can return conservative results in the case that inference variables are found.
We should file a follow-up issue (and update the FIXMEs...) to do the proper refactoring.
cc `@arora-aman`
r? `@oli-obk`
In E0716, there is a code block that is equivalent to the erroneous
code example. Especially when viewed with `rustc --explain`, it's
not obvious that it is also erroneous, and some users have been
confused when they try to change their code to match the erroneous
equivalent.
Support allocation failures when interpreting MIR
This closes#79601 by handling the case where memory allocation fails during MIR interpretation, and translates that failure into an `InterpError`. The error message is "tried to allocate more memory than available to compiler" to make it clear that the memory shortage is happening at compile-time by the compiler itself, and that it is not a runtime issue.
Now that memory allocation can fail, it would be neat if Miri could simulate low-memory devices to make it easy to see how much memory a Rust program needs.
Note that this breaks Miri because it assumes that allocation can never fail.
Warn when `rustdoc::` group is omitted from lint names
When rustdoc lints were first made a tool lint, they gave an unconditional warning when you used the original name:
```
warning: lint `broken_intra_doc_links` has been renamed to `rustdoc::broken_intra_doc_links`
--> $DIR/renamed-lint-still-applies.rs:2:9
|
LL | #![deny(broken_intra_doc_links)]
| ^^^^^^^^^^^^^^^^^^^^^^ help: use the new name: `rustdoc::broken_intra_doc_links`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
```
That was reverted in https://github.com/rust-lang/rust/pull/83203 because adding `rustdoc::x` lints would cause the code to break on old versions of the compiler (due to https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, "fixed" in https://github.com/rust-lang/rust/pull/83216 in the sense that you can now opt-in to not breaking on nightly, which is not ideal but `register_tool` is a long way from stabilizing). Since https://github.com/rust-lang/rust/pull/80527 is now on 1.52.0 stable, we can re-enable the warning. For nightly users, they can change immediately and still have their code work on stable; for stable users, they can change their code in 12 weeks and still have it work up to 3 releases back (about 18 weeks). That seems reasonable to me.
r? `@Manishearth` cc `@rust-lang/rustdoc`
Return `EvaluatedToOk` when type in outlives predicate is global
A global type doesn't reference any local regions or types, so it's
guaranteed to outlive any region.
Avoid byte to char position conversions in `is_multiline`
Converting a byte position into a char position is currently linear in
the number of multibyte characters in the source code. Avoid it when
checking if a range spans across lines.
This makes it feasible to compile source files with a large number of
multibyte characters.
deny using default function in impl const Trait
Fixes#79450.
I don't know if my implementation is correct:
- The check is in `rustc_passes::check_const`, should I put it somewhere else instead?
- Is my approach (to checking the impl) optimal? It works for the current tests, but it might have some issues or there might be a better way of doing this.
Fix const-generics ICE related to binding
Fixes#83765, fixes#85848
r? `@jackh726` as you're familiar with `Binding`. I'd like to get some views if the current approach is right path.
Previously, only the fields would be displayed with no indication of the
variant name. If you already knew the enum was univariant, this was ok
but if the enum was univariant because of layout, for example, a
`Result<T, !>` then it could be very confusing which variant was the
active one.
Previously, directly tagged enums had a `variant$` field which would
show the name of the active variant. We now show the variant using a
`[variant]` synthetic item just like we do for niche-layout enums.
Rollup of 7 pull requests
Successful merges:
- #84029 (add `track_path::path` fn for usage in `proc_macro`s)
- #85001 (Merge `sys_common::bytestring` back into `os_str_bytes`)
- #86308 (Docs: clarify that certain intrinsics are not unsafe)
- #86796 (Add a regression test for issue-70703)
- #86803 (Remove & from Command::args calls in documentation)
- #86807 (Fix double import in wasm thread )
- #86813 (Add a help message to `unused_doc_comments` lint)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add a help message to `unused_doc_comments` lint
Fixes#83492
This adds a help message to suggest a plain comment like the E0658 error. I've yet to come up with the best message about the doc attribute but the current shouldn't harm anything.
I was thinking of recovering in the `doc_comment_between_if_else` case, but I came to the conclusion that it unlikely happened and was an overkill.
add `track_path::path` fn for usage in `proc_macro`s
Adds a way to declare a dependency on external files without including them, to either re-trigger the build of a file as well as covering the use case of including dependencies within the `rustc` invocation, such that tools like `sccache`/`cachepot` are able to handle references to external files which are not included.
Ref #73921
