Attributes on struct expression fields were not being checked for
validity. This adds the fields as HIR nodes so that `CheckAttrVisitor`
can visit those nodes to check their attributes.
Attributes on pattern struct fields were not being checked for validity.
This adds the fields as HIR nodes so that the `CheckAttrVisitor` can
visit those nodes to check their attributes.
Update to LLVM 15
For preliminary testing. Some LLVM 15 compatibility fixes were applied separately in #99512.
Release timeline:
* LLVM 15 branched on Jul 26.
* The final LLVM 15.0.0 release is scheduled for Sep 6.
* Current nightly (1.65.0) is scheduled for Nov 3.
Changes in this PR (apart from the LLVM update):
* Pass `--set llvm.allow-old-toolchain` for many Docker images. LLVM 16 will require GCC >= 7.1, while LLVM 15 still allows older compilers with an option. Specify the option for builders still using GCC 5.4. #95026 updated some of the used toolchains, but not all.
* Use the `+atomics-32` target feature for thumbv6m.
* Explicitly link libatomic when cross-compiling LLVM to 32-bit target.
* Explicitly disable zstd support, to avoid libzstd.so dependency.
New LLVM patches ([commits](https://github.com/rust-lang/llvm-project/commits/rustc/15.0-2022-08-09)):
* [rust-only] Fix ICE with GCC 5.4 (15be58d7f0)
* [rust-only] Fix build with GCC 5.4 (774edc10fa)
* ~~[rust-only] Fix build with GCC 5.2 (1a6069a7bb)~~
* ~~[rust-only] Fix ICE with GCC 5.2 (493081f290)~~
* ~~[rust-only] Fix build with GCC 5.2 (0fc5979d73)~~
* [backported] Addition of `+atomics` target feature (57bdd9892d).
* [backported] Revert compiler-rt change that broke powerpc (9c68b43915)
* [awaiting backport] Fix RelLookupTableConverter on gnux32 (639388a05f / https://github.com/llvm/llvm-project/issues/57021)
Tested images: dist-x86_64-linux, armhf-gnu, arm-android, dist-s390x-linux, dist-x86_64-illumos, dist-x86_64-freebsd, wasm32, dist-x86_64-musl, dist-various-1, dist-riscv64-linux, dist-mips-linux, dist-mipsel-linux, dist-powerpc-linux, dist-aarch64-linux, dist-x86_64-apple, x86_64-msvc-1, x86_64-msvc-2, dist-various-2, dist-arm-linux
Tested up to the usual ipv6 error: test-various, i686-gnu, x86_64-gnu-nopt
r? `@ghost`
Stringify non-shorthand visibility correctly
This makes `stringify!(pub(in crate))` evaluate to `pub(in crate)` rather than `pub(crate)`, matching the behavior before the `crate` shorthand was removed. Further, this changes `stringify!(pub(in super))` to evaluate to `pub(in super)` rather than the current `pub(super)`. If the latter is not desired (it is _technically_ breaking), it can be undone.
Fixes#99981
`@rustbot` label +C-bug +regression-from-stable-to-beta +T-compiler
Fix flags when using clang as linker for Fuchsia
Don't add C runtime or set dynamic linker when linking with clang for
Fuchsia. Clang already does this for us.
Use `&mut Diagnostic` instead of `&mut DiagnosticBuilder` unless needed
This seems to be the established convention (02ff9e0) when `DiagnosticBuilder` was first added. I am guilty of introducing some of these.
Remove duplicated temporaries creating during box derefs elaboration
Temporaries created with `MirPatch::new_temp` will be declared after
patch application. Remove manually created duplicate declarations.
Removing duplicates exposes another issue. Visitor elaborates
terminator twice and attempts to access new, but not yet available,
local declarations. Remove duplicated call to `visit_terminator`.
Extracted from #99946.
Determine match_has_guard from candidates instead of looking up thir table again
Currently looking through mir build of matches because of interest in deref patterns. Finding some micro-optimizable things.
Check if enum from foreign crate has any non exhaustive variants when attempting a cast
Fixes#91161
As stated in the issue, this will require a crater run as it might break other people's stuff.
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`
#100312 was the wrong approach, I think this is the right one.
When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.
Fixes#100217Fixes#83972Fixes#84669Fixes#86710Fixes#82268Fixes#73298
Currently it's reported as either `TraitItem` or `ImplItem`. This commit
changes it to `AssocItem`, because having the report match the type name
is (a) consistent with other types, and (b) the trait/impl split isn't
that important here.
This commit:
- Adds a comment explaining which `visit_*` methods should be
implemented.
- Adds and removes some `visit_*` methods accordingly, improving
coverage, and avoiding some double counting.
Add support for link-flavor rust-lld for macOS
Also refactor iOS, watchOS and tvOS common code.
The ``-arch`` argument was moved to the ``apple_base`` module instead of the target definitions for macOS.
As ld64 requires ``-syslibroot`` to be passed, ``add_apple_sdk`` was modified accordingly.
If a primary bundle doesn't contain a message then the fallback bundle
is used. However, if the primary bundle's message is broken (e.g. it
refers to a interpolated variable that the compiler isn't providing)
then this would just result in a compiler panic. While there aren't any
primary bundles right now, this is the type of issue that could come up
once translation is further along.
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 8 pull requests
Successful merges:
- #99573 (Stabilize backtrace)
- #100069 (Add error if link_ordinal used with unsupported link kind)
- #100086 (Add more `// unit-test`s to MIR opt tests)
- #100332 (Rename integer log* methods to ilog*)
- #100334 (Suggest a missing semicolon before an array)
- #100340 (Iterate generics_def_id_map in reverse order to fix P-critical issue)
- #100345 (docs: remove repetition in `is_numeric` function docs)
- #100352 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add error if link_ordinal used with unsupported link kind
The `link_ordinal` attribute only has an affect if the `raw-dylib` link kind is used, so add an error if it is used with any other link kind.
Stabilize backtrace
This PR stabilizes the std::backtrace module. As of #99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized.
Previous discussion can be found in #72981, #3156.
Stabilized API summary:
```rust
pub mod std {
pub mod backtrace {
pub struct Backtrace { }
pub enum BacktraceStatus {
Unsupported,
Disabled,
Captured,
}
impl fmt::Debug for Backtrace {}
impl Backtrace {
pub fn capture() -> Backtrace;
pub fn force_capture() -> Backtrace;
pub const fn disabled() -> Backtrace;
pub fn status(&self) -> BacktraceStatus;
}
impl fmt::Display for Backtrace {}
}
}
```
`@yaahc`
Set tainted errors bit before emitting coerce suggestions.
Fixes#100246.
#89576 basically got 99% of the way there but the match typechecking code (which calls `coerce_inner`) also needed a similar fix.
Add some high-level docs to `FnCtxt` and `ItemCtxt`
I haven't understood the difference between these before, but
``@compiler-errors`` helped me clear it up. Hopefully this will help other
people who've been confused!
r? `@compiler-errors`
Some "this expression has a field"-related fixes
Each commit does something different and is worth reviewing, but the final diff from `master..HEAD` contains the sum of the changes to the UI tests, since some commits added UI tests "regressions" which were later removed in other commits.
The only change I could see adding on top of this is suppressing `Clone::clone` from the "this expression has a field that has this method" suggestion, since it's so commonly implemented by types that it's not worthwhile suggesting in general.
Error on broken pipe but do not backtrace or ICE
Windows will report a broken pipe as a normal error which in turn `println!` will panic on. Currently this causes rustc to produce a backtrace and ICE. However, this is not a bug with rustc so a backtrace is overly verbose and ultimately unhelpful to the user.
Kind of fixes#98700. Although this is admittedly a bit of a hack because at panic time all we have is a string to inspect. On zulip it was suggested that libstd might someday provide a way to indicate a soft panic but that day isn't today.
consider unnormalized types for implied bounds
extracted, and slightly modified, from #98900
The idea here is that generally, rustc is split into things which can assume its inputs are well formed[^1], and things which have verify that themselves.
Generally most predicates should only deal with well formed inputs, e.g. a `&'a &'b (): Trait` predicate should be able to assume that `'b: 'a` holds. Normalization can loosen wf requirements (see #91068) and must therefore not be used in places which still have to check well formedness. The only such place should hopefully be `WellFormed` predicates
fixes#87748 and #98543
r? `@jackh726` cc `@rust-lang/types`
[^1]: These places may still encounter non-wf inputs and have to deal with them without causing an ICE as we may check for well formedness out of order.
Re-structure the stability checks for library features to avoid calling
`defined_lib_features` for any more crates than necessary for each of
the implications or local feature attributes that need validation.
Don't ICE while suggesting updating item path.
When an item isn't found, we may suggest an appropriate import to `use`. Along with that, we also suggest updating the path to work with the `use`. Unfortunately, if the code in question originates from a macro, the span used to indicate which part of the path needs updating may not be suitable and cause an ICE (*). Since, such code is not adjustable directly by the user without modifying the macro, just skip the suggestion in such cases.
(*) The ICE happens because the emitter want to indicate to the user what code to delete by referencing a certain span. But in this case, said span has `lo == hi == 0` which means it thinks it's a dummy span. Adding a space before the proc macro attribute is enough to stop it from ICE'ing but even then the suggestion doesn't really make any sense:
```
help: if you import `DataStore`, refer to it directly
|
1 - #[dbstruct::dbstruct]
1 + #[dbstruct::dbstruct]
```
Since suggestions are best-effort, I just gated this one on `can_be_used_for_suggestions` which catches cases like this.
Fixes#100199
Don't document impossible to call default trait items on impls
Closes#100176
This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.
Implement `#[rustc_default_body_unstable]`
This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.
`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
#[rustc_default_body_unstable(feature = "feat", isssue = "none")]
fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`
This is useful in conjunction with [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/pull/92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.
r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
Add option to `mir::MutVisitor` to not invalidate CFG.
This also applies that option to some uses of the visitor. I had considered a design more similar to #100087 in which we detect if the CFG needs to be invalidated, but that is more difficult with the visitor API and so I decided against it. Another alternative to this design is to offer an API for "saving" and "restoring" CFG caches across arbitrary code. Such an API is more general, and so we may eventually want it anyway, but it seems overkill for this use case.
r? `@tmiasko`
https://reviews.llvm.org/D120026 changed atomics on thumbv6m to
use libatomic, to ensure that atomic load/store are compatible with
atomic RMW/CAS. However, Rust wants to expose only load/store
without libcalls.
https://reviews.llvm.org/D130480 added support for this behind
the +atomics-32 target feature, so enable that feature.
Instead of a FxHashMap<Symbol, (usize, Span)> for the named arguments,
this now includes the name and span in the elements of the
Vec<FormatArg> directly. The FxHashMap still exists to look up the
index, but no longer contains the span. Looking up the name or span of
an argument is now trivial and does not need the map anymore.
Implement special-cased projection error message for some common traits
Not sure what the best phrasing is, but I feel like these are more clear than the plain `<Type as Iterator>::Output == Type` messages.
If this is actually a good idea, are there any other traits this could benefit?
I haven't understood the difference between these before, but
`@compiler-errors` helped me clear it up. Hopefully this will help other
people who've been confused!
Add armv4t-none-eabi take2
This is the same as the previous PR (https://github.com/rust-lang/rust/pull/99226) but i just made a fresh branch without a merge commit in it.
---
### armv4t-none-eabi target quiz
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target.
That's me!
> Targets must use naming consistent with any existing targets
We're using the existing name as recognized by LLVM and GCC
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
No legal issues here.
>> The target must not introduce license incompatibilities.
No license requirements here.
>> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
check
>> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy.
no new deps, we're just adding a rustc target description file for a target llvm already knows about.
>> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries.
bare-metal target, doesn't rely on any libs at all.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate
`core` only here. You could build `alloc` too, but you'd have to bring your own global allocator.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
LLVM knows how to do it, you just need the GNU Binutils linker because LLVM's linker doesn't work that far back. That's in the docs as part of this PR.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.
No burdens, LLVM already knows how to do this. Further, because this is a cpu-feature variant of an existing tier3 target the `compiler-builtins` crate has already been updated as necessary to fix any missing builtin function gaps.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
check.
Use start_point instead of next_point to point to elided lifetime amp…
Using `next_point` creates a span which points inside the multibyte token, ICEing.
Fixes https://github.com/rust-lang/rust/issues/100224
Multiple duplicate assignments of the same discriminant are now reported
in the samme error. We now point out the incrementation start point for
discriminants that are not explicitly assigned that are also duplicates.
Removed old test related to E0081 that is now covered by error-codes/E0081.rs.
Also refactored parts of the `check_enum` function.
When an item isn't found, we may suggest an appropriate import to
`use`. Along with that, we also suggest updating the path to work
with the `use`. Unfortunately, if the code in question originates
from a macro, the span used to indicate which part of the path
needs updating may not be suitable and cause an ICE. Since, such
code is not adjustable directly by the user without modifying the
macro, just skip the suggestion in such cases.
Check link ordinal to make sure it is targetted for foreign function
Fix#100009, when link ordinal is not target for foreign functions, emit an error.
cc `@dpaoliello`
Avoid pointing out `return` span if it has nothing to do with type error
This code:
```rust
fn f(_: String) {}
fn main() {
let x = || {
if true {
return ();
}
f("");
};
}
```
Emits this:
```
Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
--> src/main.rs:8:11
|
8 | f("");
| ^^- help: try using a conversion method: `.to_string()`
| |
| expected struct `String`, found `&str`
|
note: return type inferred to be `String` here
--> src/main.rs:6:20
|
6 | return ();
| ^^
```
Specifically, that note has nothing to do with the type error in question. This is because the change implemented in #84244 tries to point out the `return` span on _any_ type coercion error within a closure that happens after a `return` statement, regardless of if the error has anything to do with it.
This is really easy to trigger -- just needs a closure (or an `async`) and an early return (or any other form, e.g. `?` operator suffices) -- and super distracting in production codebases. I'm letting #84128 regress because that issue is much harder to fix correctly, and I can re-open that issue after this lands.
As a drive-by, I added a `resolve_vars_if_possible` to the coercion error logic, which leads to some error improvements. Unrelated to the issue above, though.
Rollup of 4 pull requests
Successful merges:
- #100094 (Detect type mismatch due to loop that might never iterate)
- #100132 (Use (actually) dummy place for let-else divergence)
- #100167 (Recover `require`, `include` instead of `use` in item)
- #100193 (Remove more Clean trait implementations)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Detect type mismatch due to loop that might never iterate
When loop as tail expression causes a miss match type E0308 error, recursively get the return statement and add diagnostic information on it.
Temporaries created with `MirPatch::new_temp` will be declared after
patch application. Remove manually created duplicate declarations.
Removing duplicates exposes another issue. Visitor elaborates
terminator twice and attempts to access new, but not yet available,
local declarations. Remove duplicated call to `visit_terminator`.
Enable function merging when opt is for size
It is, of course, natural to want to merge aliasing functions when
optimizing for code size, since that can eliminate several bytes.
And an exhaustive match helps make the code less brittle.
Closes#98215.
It is, of course, natural to want to merge aliasing functions when
optimizing for code size, since that can eliminate several bytes.
And an exhaustive match helps make the code less brittle.
when loop as tail expression for miss match type E0308 error, recursively get
the return statement and add diagnostic information on it
use rustc_hir::intravisit to collect the return expression
modified: compiler/rustc_typeck/src/check/coercion.rs
new file: src/test/ui/typeck/issue-98982.rs
new file: src/test/ui/typeck/issue-98982.stderr
Improve diagnostics for `const a: = expr;`
Adds a suggestion to write a type when there is a colon, but the type is not present.
I've also shrunk spans a little, so the suggestions are a little nicer.
Resolves#100146
r? `@compiler-errors`
Add test for raw-dylib with an external variable
All existing tests of link kind `raw-dylib` only validate the ability to link against functions, but it is also possible to link against variables.
This adds tests for linking against a variable using `raw-dylib` both by-name and by-ordinal.
Warn about dead tuple struct fields
Continuation of #92972. Fixes#92790.
The language team has already commented on this in https://github.com/rust-lang/rust/pull/92972#issuecomment-1021511970; I have incorporated their requests here. Specifically, there is now a new allow-by-default `unused_tuple_struct_fields` lint (name bikesheddable), and fields of unit type are ignored (https://github.com/rust-lang/rust/pull/92972#issuecomment-1021815408), so error messages look like this:
```
error: field is never read: `1`
--> $DIR/tuple-struct-field.rs:6:21
|
LL | struct Wrapper(i32, [u8; LEN], String);
| ^^^^^^^^^
|
help: change the field to unit type to suppress this warning while preserving the field numbering
|
LL | struct Wrapper(i32, (), String);
| ~~
```
r? `@joshtriplett`
Split create_def and lowering of lifetimes for opaque types and bare async fns
r? `@cjgillot`
This work is kind of half-way, but I think it could be merged anyway.
I think we should be able to remove all the vacant arms in `new_named_lifetime_with_res`, if I'm not wrong that requires visiting more nodes. We can do that as a follow up.
In follow-up PRs, besides the thing mentioned previously, I'll be trying to remove `LifetimeCaptureContext`, `captured_lifetimes` as a global data structure, global `binders_to_ignore` and all their friends :).
Also try to remap in a more general way based on def-ids.
Enable unused_parens for match arms
Fixes: https://github.com/rust-lang/rust/issues/92751
Currently I can't get the `stderr` to work with `./x.py test`, but this should fix the issue. Help would be appreciated!
Avoid invalidating the CFG in `MirPatch`
As a part of this change, we adjust `MirPatch` to not needlessly create unnecessary resume blocks.
r? `@tmiasko`
Always create elided lifetimes, even if inferred.
`PathSource` gives the context in which a path is encountered. The same `PathSource` is used for the full path and the `QSelf` part.
Therefore, we can only rely on `PathSource` to know whether typechecking will be able to infer the lifetimes, not whether we need to insert them at all.
Fixes https://github.com/rust-lang/rust/issues/99949
Some `is_useful` cleanups
#98582 was reverted because it was a perf regression.
https://github.com/rust-lang/rust/pull/99806 reintroduces the changes, but this PR picks individual ones that have no regressions.
Rollup of 6 pull requests
Successful merges:
- #98771 (Add support for link-flavor rust-lld for iOS, tvOS and watchOS)
- #98835 (relate `closure_substs.parent_substs()` to parent fn in NLL)
- #99746 (Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`)
- #99786 (Recover from C++ style `enum struct`)
- #99795 (Delay a bug when failed to normalize trait ref during specialization)
- #100029 (Prevent ICE for `doc_alias` on match arm, statement, expression)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Prevent ICE for `doc_alias` on match arm, statement, expression
Fixes#99777.
This is a pretty minimal fix that should be safe, since rustdoc doesn't generate documentation for match arms, statements, or expressions. I mentioned in the linked issue that the `doc_alias` target checking should probably be improved to avoid future ICEs, but as a new contributor, I'm not confident enough with the HIR types to make a larger change.
Delay a bug when failed to normalize trait ref during specialization
The error messages still kinda suck here but they don't ICE anymore...
Fixes#45814Fixes#43037
r? types
Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`
Not sure if this change is worthwhile, but couldn't hurt re: chalkification
r? types
relate `closure_substs.parent_substs()` to parent fn in NLL
Fixes#98589
The discrepancy between early- and late-bound lifetimes is because we map early-bound lifetimes into those found in the `closure_substs` while late-bound lifetimes are mapped into liberated free regions:
5f98537eb7/compiler/rustc_borrowck/src/universal_regions.rs (L255-L261)
r? `@rust-lang/types`
Add support for link-flavor rust-lld for iOS, tvOS and watchOS
This adds support for rust-lld for Apple *OS targets.
This was tested against targets ``aarch64-apple-ios`` and ``aarch64-apple-ios-sim`` with [a simple test program](https://github.com/Thog/rust-lld-apple-target_test).
It currently doesn't work with targets ``armv7-apple-ios`` and ``armv7s-apple-ios`` because of ``symbols.o`` not being generated with the correct CPU subtype. This will require changes in the ``object`` crate to expose an API.
As ``ld64.lld`` requires ``-platform_version`` with the minimal version supported and an sdk version, I made ``rustc_target::apple_base`` public to get access to ``*os_deployment_target`` helper functions and also added ``tvos_deployment_target`` as it was missing.
This adds support for rust-lld for Apple *OS targets.
This was tested against targets "aarch64-apple-ios" and "aarch64-apple-ios-sim".
For targets "armv7-apple-ios" and "armv7s-apple-ios", it doesn't link because of
"symbols.o" not being generated with the correct CPU subtype (changes in
the "object" crate needs to be done to support it).
Rollup of 6 pull requests
Successful merges:
- #99933 (parallelize HTML checking tool)
- #99958 (Improve position named arguments lint underline and formatting names)
- #100008 (Update all pre-cloned submodules on startup)
- #100049 (⬆️ rust-analyzer)
- #100070 (Clarify Cargo.toml comments)
- #100074 (rustc-docs: Be less specific about the representation of `+bundle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
remove `commit_unconditionally`
`commit_unconditionally` is a noop unless we somehow inspect the current state of our snapshot. The only thing which does that is the leak check which was only used in one place where `commit_if_ok` is probably at least as, or even more, correct.
r? rust-lang/types
Improve position named arguments lint underline and formatting names
For named arguments used as implicit position arguments, underline both
the opening curly brace and either:
* if there is formatting, the next character (which will either be the
closing curl brace or the `:` denoting the start of formatting args)
* if there is no formatting, the entire arg span (important if there is
whitespace like `{ }`)
This should make it more obvious where the named argument should be.
Additionally, in the lint message, emit the formatting argument names
without a dollar sign to avoid potentially confusion.
Fixes#99907
Properly reject the `may_unwind` option in `global_asm!`
This was accidentally accepted even though it had no effect in
`global_asm!`. The option only makes sense for `asm!` which runs within
a function.
Always include a position span in `rustc_parse_format::Argument`
Moves the spans from the `Position` enum to always be included in the `Argument` struct. Doesn't make any changes to use it in rustc, but it will be useful for some upcoming Clippy lints
make `PlaceholderConst` not store the type of the const
Currently the `Placeholder` variant on `ConstKind` is 28 bytes when with this PR its 8 bytes, i am not sure this is really useful at all rn since `Unevaluated` and `Value` variants are huge still but eventually it should be possible to get both down to 16 bytes 🤔. Mostly opening this to see if this change has any perf impact when done before it can make `ConstKind`/`ConstS` smaller
For named arguments used as implicit position arguments, underline both
the opening curly brace and either:
* if there is formatting, the next character (which will either be the
closing curl brace or the `:` denoting the start of formatting args)
* if there is no formatting, the entire arg span (important if there is
whitespace like `{ }`)
This should make it more obvious where the named argument should be.
Additionally, in the lint message, emit the formatting argument names
without a dollar sign to avoid potentially confusion.
Fixes#99907
Use Parser's `restrictions` instead of `let_expr_allowed`
This also means that the `ALLOW_LET` flag is reset properly for subexpressions, so we can properly deny things like `a && (b && let c = d)`. Also the parser is a tiny bit smaller now.
It doesn't reject _all_ bad `let` expr usages, just a bit more.
cc `@c410-f3r`
`codegen_fulfill_obligation` expect erased regions
it's a query, so by erasing regions before calling it, we get better caching.
This doesn't actually change anything as its already the status quo.
Thin `AssocItem`
This PR removes a few fields from `AssocItem` that should be easily computed using other queries.
This simplifies some of the metadata decoding.
Add tests for raw-dylib with vectorcall, and fix vectorcall code generation
* Adds tests for using `raw-dylib` (#58713) with `vectorcall`.
* Fixed code generation for `vectorcall` (parameters have to be marked with `InReg`, just like `fastcall`).
* Enabled running the `raw-dylib` `fastcall` tests when using MSVC (since I had to add support in the test for running MSVC-only tests since GCC doesn't support `vectorcall`).
Rollup of 8 pull requests
Successful merges:
- #99340 (Fix ICE in Definitions::create_def)
- #99629 (Improve `cannot move out of` error message)
- #99864 (bootstrap: don't emit warn about duplicated deps with same/different features if some of sets actually empty)
- #99911 (Remove some uses of `guess_head_span`)
- #99976 (Make Rustdoc exit with correct error code when scraping examples from invalid files)
- #100003 (Improve size assertions.)
- #100012 (Avoid `Ty` to `String` conversions)
- #100020 (better error when python is not found in x - issue #99648)
Failed merges:
- #99994 (Replace `guess_head_span` with `opt_span`)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve size assertions.
- For any file with four or more size assertions, move them into a
separate module (as is already done for `hir.rs`).
- Add some more for AST nodes and THIR nodes.
- Put the `hir.rs` ones in alphabetical order.
r? `@lqd`
Fix ICE in Definitions::create_def
`Debug` implementation for `LocalDefId` uses global `Definitions`. Normally it’s ok, but we can’t do it while holding a mutable reference to `Definitions`, since it causes ICE or deadlock (depending on whether `parallel_compiler` is enabled).
This PR effectively copies the `Debug` implementation into the problematic method. I don’t particularly love this solution (since it creates code duplication), but I don’t see any other options.
This issue was discovered when running `rustdoc` with `RUSTDOC_LOG=trace` on the following file:
```rust
pub struct SomeStruct;
fn asdf() {
impl SomeStruct {
pub fn qwop(&self) {
println!("hidden function");
}
}
}
```
I’m not sure how to create a test for this behavior.
Limit symbols exported from proc macros
Only `__rustc_proc_macro_decls_*__` and `rust_metadata_*` need to be
exported for proc macros to work. All other symbols only increase binary
size and have the potential to conflict with symbols from the host
compiler.
Fixes https://github.com/rust-lang/rust/issues/99909Fixes#59998
cc `@eddyb`
Rollup of 7 pull requests
Successful merges:
- #99519 (Remove implicit names and values from `--cfg` in `--check-cfg`)
- #99620 (`-Z location-detail`: provide option to disable all location details)
- #99932 (Fix unwinding on certain platforms when debug assertions are enabled)
- #99973 (Layout things)
- #99980 (Remove more Clean trait implementations)
- #99984 (Fix compat.rs for `cfg(miri)`)
- #99986 (Add wrap suggestions for record variants)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
- For any file with four or more size assertions, move them into a
separate module (as is already done for `hir.rs`).
- Add some more for AST nodes and THIR nodes.
- Put the `hir.rs` ones in alphabetical order.
From 72 bytes to 12 bytes (on x86-64).
There are two parts to this:
- Changing various source code offsets from 64-bit to 32-bit. This is
not a problem because the rest of rustc also uses 32-bit source code
offsets. This means `Token` is no longer `Copy` but this causes no
problems.
- Removing the `RawStrError` from `LiteralKind`. Raw string literal
invalidity is now indicated by a `None` value within
`RawStr`/`RawByteStr`, and the new `validate_raw_str` function can be
used to re-lex an invalid raw string literal to get the `RawStrError`.
There is one very small change in behaviour. Previously, if a raw string
literal matched both the `InvalidStarter` and `TooManyHashes` cases,
the latter would override the former. This has now changed, because
`raw_double_quoted_string` now uses `?` and so returns immediately upon
detecting the `InvalidStarter` case. I think this is a slight
improvement to report the earlier-detected error, and it explains the
change in the `test_too_many_hashes` test.
The commit also removes a couple of comments that refer to #77629 and
say that the size of these types don't affect performance. These
comments are wrong, though the performance effect is small.
Currently we skip deriving `PartialEq::ne` for C-like (fieldless) enums
and empty structs, thus reyling on the default `ne`. This behaviour is
unnecessarily conservative, because the `PartialEq` docs say this:
> Implementations must ensure that eq and ne are consistent with each other:
>
> `a != b` if and only if `!(a == b)` (ensured by the default
> implementation).
This means that the default implementation (`!(a == b)`) is always good
enough. So this commit changes things such that `ne` is never derived.
The motivation for this change is that not deriving `ne` reduces compile
times and binary sizes.
Observable behaviour may change if a user has defined a type `A` with an
inconsistent `PartialEq` and then defines a type `B` that contains an
`A` and also derives `PartialEq`. Such code is already buggy and
preserving bug-for-bug compatibility isn't necessary.
Two side-effects of the change:
- There is only one error message produced for types where `PartialEq`
cannot be derived, instead of two.
- For coverage reports, some warnings about generated `ne` methods not
being executed have disappeared.
Both side-effects seem fine, and possibly preferable.
Fix cloning from a BitSet with a different domain size
The previous implementation incorrectly assumed that the
number of words in a bit set is equal to the domain size.
The new implementation delegates to `Vec::clone_from` which
is specialized for `Copy` elements.
Fixes#99006.
Add wrap suggestions for record variants
This PR adds a suggestions to wrap an expression in a record struct/variant when encountering mismatched types, similarly to a suggestion to wrap expression in a tuple struct that was added before.
An example:
```rust
struct B {
f: u8,
}
enum E {
A(u32),
B { f: u8 },
}
fn main() {
let _: B = 1;
let _: E = 1;
}
```
```text
error[E0308]: mismatched types
--> ./t.rs:11:16
|
11 | let _: B = 1;
| - ^ expected struct `B`, found integer
| |
| expected due to this
|
help: try wrapping the expression in `B`
|
11 | let _: B = B { f: 1 };
| ++++++ +
error[E0308]: mismatched types
--> ./t.rs:12:16
|
12 | let _: E = 1;
| - ^ expected enum `E`, found integer
| |
| expected due to this
|
help: try wrapping the expression in a variant of `E`
|
12 | let _: E = E::A(1);
| +++++ +
12 | let _: E = E::B { f: 1 };
| +++++++++ +
```
r? `@compiler-errors`
Layout things
These two commits are pretty independent, but didn't seem worth doing individual PRs for:
- Always check that size is a multiple of align, even without debug assertions
- Change Layout debug printing to put `variants` last, since it often huge and not usually the part we are most interested in
Cc `@eddyb`
`-Z location-detail`: provide option to disable all location details
As reported [here](https://github.com/rust-lang/rust/pull/89920#issuecomment-1190598924), when I first implemented the `-Z location-detail` flag there was a bug, where passing an empty list was not correctly supported, and instead rejected by the compiler. This PR fixes that such that passing an empty list results in no location details being tracked, as originally specified in https://github.com/rust-lang/rfcs/pull/2091 .
This PR also adds a test case to verify that this option continues to work as intended.
Remove implicit names and values from `--cfg` in `--check-cfg`
This PR remove the implicit names and values from `--cfg` in `--check-cfg` because the behavior is quite surprising but also because it's really easy to inadvertently really on the implicitness and when the `--cfg` is not set anymore to have an unexpected warning from an unexpected condition that pass with the implicitness.
This change in behavior will also enable us to warn when an unexpected `--cfg` is passed, ex: the user wrote `--cfg=unstabl` instead of `--cfg=unstable`. The implementation of the warning will be done in a follow-up PR.
cc `@petrochenkov`
Suggest removing a semicolon and boxing the expressions for if-else
`InferCtxt::suggest_remove_semi_or_return_binding` was not working well, so I fixed it and added a ui test.
Introduce an ArchiveBuilderBuilder
This avoids monomorphizing all linker code for each codegen backend and will allow passing in extra information to the archive builder from the codegen backend. I'm going to use this in https://github.com/rust-lang/rust/pull/97485 to allow passing in the right function to extract symbols from object files to a generic archive builder to be used by cg_llvm, cg_clif and cg_gcc.
Use `impl`'s generics when suggesting fix on bad `impl Copy`
See the UI test for a more complicated example, but we weren't correctly suggesting to add bounds given a manual `impl` whose generics didn't match the struct generics.
```rust
#[derive(Clone)]
struct Wrapper<T>(T);
impl<S> Copy for Wrapper<S> {}
```
Coincidentally this fix didn't cause any regressions for `derive(Copy)` impls, I think because those use the same spans in the impl generics as the struct generics, so the machinery still applies the same change.
Fix the size of niche enums with ZST alignment
For enums with an aligned ZST variant, like `[T; 0]`, the niche layout
was not computing a sufficient size to be consistent with alignment. Now
we pad that size up to the alignment, and also make sure to only use the
niche variant's ABI when the size and alignment still match.
Fixes#99836
r? `@eddyb`
Also gate AllocatedPointer and AllocAlign definitions by LLVM_VERSION_GE
Fixes a warning:
```
warning: llvm-wrapper/RustWrapper.cpp:159:11: warning: enumeration values 'AllocatedPointer' and 'AllocAlign' not handled in switch [-Wswitch]
warning: switch (Kind) {
warning: ^
```
Which was fall out from 130a1df71e.
Fixes#99955
For enums with an aligned ZST variant, like `[T; 0]`, the niche layout
was not computing a sufficient size to be consistent with alignment. Now
we pad that size up to the alignment, and also make sure to only use the
niche variant's ABI when the size and alignment still match.
Rollup of 5 pull requests
Successful merges:
- #99311 (change maybe_body_owned_by to take local def id)
- #99862 (Improve type mismatch w/ function signatures)
- #99895 (don't call type ascription "cast")
- #99900 (remove some manual hash stable impls)
- #99903 (Add diagnostic when using public instead of pub)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixes a warning:
warning: llvm-wrapper/RustWrapper.cpp:159:11: warning: enumeration values 'AllocatedPointer' and 'AllocAlign' not handled in switch [-Wswitch]
warning: switch (Kind) {
warning: ^
Which was fall out from 130a1df71e.
Add diagnostic when using public instead of pub
Forwarding from https://github.com/rust-lang/rust/pull/99706
I accidentally broke something(??) in git and the commits in that PR are absolutely not what I did in that branch
Anyways, this is the PR for this now. Adding tests again in a minute.
cc `@davidtwco`
Improve type mismatch w/ function signatures
This PR makes use of `note: expected/found` (instead of labeling types in labels) in type mismatch with function signatures. Pros: it's easier to compare the signatures, cons: the error is a little more verbose now.
This is especially nice when
- The signatures differ in a small subset of parameters (same parameters are elided)
- The difference is in details, for example `isize` vs `usize` (there is a better chance that the types align)
Also this PR fixes the inconsistency in variable names in the edited code (`expected` and `found`).
A zulip thread from which this pr started: [[link]](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Type.20error.20regression.3F.2E.2E.2E/near/289756602).
An example diagnostic:
<table>
<tr>
<th>this pr</th>
<th>nightly</th>
</tr>
<tr>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected due to this
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature defined here
|
= note: expected function signature `fn(usize, _, Vec<u64>) -> _`
found function signature `fn(isize, _, Vec<u32>) -> _`
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast from `fn(isize, u8, Vec<u32>) {f}` to the object type `dyn Trait`
```
</td>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected signature of `fn(usize, u8, Vec<u64>) -> _`
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature of `fn(isize, u8, Vec<u32>) -> _`
|
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast to the object type `dyn Trait`
```
</td>
</tr>
</table>
<details><summary>code</summary>
<p>
```rust
fn main() {
fn expect(_: &dyn Trait) {}
expect(&f);
}
trait Trait {}
impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
fn f(_: isize, _: u8, _: Vec<u32>) {}
```
</p>
</details>
r? `@compiler-errors`
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
r? `@petrochenkov`
Only __rustc_proc_macro_decls_*__ and rust_metadata_* need to be
exported for proc macros to work. All other symbols only increase binary
size and have the potential to conflict with symbols from the host
compiler.
use `check_region_obligations_and_report_errors` to avoid ICEs
If we don't call `process_registered_region_obligations` before `resolve_regions_and_report_errors` then we'll ICE if we have any region obligations, and `check_region_obligations_and_report_errors` just does both of these for us in a nice convenient function.
Fixes#53475
r? types
proc_macro: use crossbeam channels for the proc_macro cross-thread bridge
This is done by having the crossbeam dependency inserted into the `proc_macro` server code from the server side, to avoid adding a dependency to `proc_macro`.
In addition, this introduces a -Z command-line option which will switch rustc to run proc-macros using this cross-thread executor. With the changes to the bridge in #98186, #98187, #98188 and #98189, the performance of the executor should be much closer to same-thread execution.
In local testing, the crossbeam executor was substantially more performant than either of the two existing `CrossThread` strategies, so they have been removed to keep things simple.
r? `@eddyb`
Rollup of 8 pull requests
Successful merges:
- #99227 (Fix thumbv4t-none-eabi frame pointer setting)
- #99518 (Let-else: break out scopes when a let-else pattern fails to match)
- #99671 (Suggest dereferencing index when trying to use a reference of usize as index)
- #99831 (Add Fuchsia platform support documentation)
- #99881 (fix ICE when computing codegen_fn_attrs on closure with non-fn parent)
- #99888 (Streamline lint checking)
- #99891 (Adjust an expr span to account for macros)
- #99904 (Cleanup html whitespace)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adjust an expr span to account for macros
Fix this erroneous suggestion:
```
error[E0529]: expected an array or slice, found `Vec<{integer}>`
--> /home/gh-compiler-errors/test.rs:2:9
|
2 | let [..] = vec![1, 2, 3];
| ^^^^ pattern cannot match with input type `Vec<{integer}>`
|
help: consider slicing here
--> /home/gh-compiler-errors/rust2/library/alloc/src/macros.rs:50:36
|
50~ $crate::__rust_force_expr!(<[_]>::into_vec(
51+ #[rustc_box]
52+ $crate::boxed::Box::new([$($x),+])
53~ )[..])
```
Streamline lint checking
The early (AST) and late (HIR) lint checkers have a number of functions that aren't used by rustc or clippy. Might as well remove them -- it's not like there's a canonical API here, as shown by the ad hoc use of `check_foo`/`check_foo_post` combinations.
r? `@cjgillot`
fix ICE when computing codegen_fn_attrs on closure with non-fn parent
Other call sites check `has_codegen_attrs` first, so let's do that too.
Fixes#99876
Let-else: break out scopes when a let-else pattern fails to match
This PR will commit to a new behavior so that values from initializer expressions are dropped earlier when a let-else pattern fails to match.
Fix#98672.
Close#93951.
cc `@camsteffen` `@est31`
Fix thumbv4t-none-eabi frame pointer setting
The `thumb_base` profile has changed since I last remember seeing it, and now it sets the frame pointer to "always keep", which is not desired for this target. Hooking a debugger to the running program is not really done, it's preferable to have the register available for actual program use, so the default "may omit" is now set.
I thought that the target was already using "may omit" when I checked on it last month, because I forgot that the target was previously based on `thumb_base` rather than `Default::default()`. I only noticed the issue just now when creating the `armv4t-none-eabi` target (https://github.com/rust-lang/rust/pull/99226), though this PR is not in any way conditional on that one.
This is done by having the crossbeam dependency inserted into the
proc_macro server code from the server side, to avoid adding a
dependency to proc_macro.
In addition, this introduces a -Z command-line option which will switch
rustc to run proc-macros using this cross-thread executor. With the
changes to the bridge in #98186, #98187, #98188 and #98189, the
performance of the executor should be much closer to same-thread
execution.
In local testing, the crossbeam executor was substantially more
performant than either of the two existing CrossThread strategies, so
they have been removed to keep things simple.
Rollup of 8 pull requests
Successful merges:
- #99686 (add suggestion when there is a impl of external trait on pointer with wrong coherence rules)
- #99760 (doc/rustc: describe the uefi target platforms)
- #99766 (Htmldocck: Substitute the doc channel when blessing)
- #99781 (Use String::from_utf8_lossy in CStr demo)
- #99803 (Update mentions to `rustc_metadata::rmeta::Lazy`)
- #99845 (Remove `$` prefix for bash scripts in doc)
- #99850 (rustdoc: Remove more Clean trait implementations)
- #99872 (Clone the `src/llvm-project` submodule if profiling is enabled)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update mentions to `rustc_metadata::rmeta::Lazy`
While working on https://github.com/rust-lang/rustc-dev-guide/pull/1411, I noticed there are still some mentions of `Lazy`. This updates them to `LazyValue`, `LazyArray`, or `LazyTable`.
r? ````@compiler-errors````
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
add suggestion when there is a impl of external trait on pointer with wrong coherence rules
Closes https://github.com/rust-lang/rust/issues/99572
This will try to improve the node in the error message by suggesting a general solution because the solution, in this case, is application depended.
I'm not super happy regarding the code quality, but I'm happy to have feedback on it.
`@rustbot` r? `@compiler-errors`
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
Generate correct suggestion with named arguments used positionally
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes#99265Fixes#99266
LLVM 15 compatibility fixes
These are LLVM 15 compatibility fixes split out from #99464. There are three changes here:
* Emit elementtype attribtue for ldrex/strex intrinsics. This is requires as part of the opaque pointers migration.
* Make more tests compatible with opaque pointers. These are either new or aren't run on x86.
* Remove a test for `#[rustc_allocator]`. Since #99574 there are more requirement on the function signature. I dropped the test entirely, since we already test the effect of the attribute elsewhere.
* The main change: When a worker thread emits an error, wait for other threads to finish before unwinding the main thread and exiting. Otherwise workers may end up using globals for which destructors have already been run. This was probably never quite correct, but became an active problem with LLVM 15, because it started using global dtors in critical places, as part of ManagedStatic removal.
Fixes#99432 (and probably also #95679).
r? `@cuviper`
Prior to this fix, `-Z location-detail` provided no mechanism for
disabling all location details. This commit also adds a test case
to verify that this option continues to work as intended, and
clarifies the documentation of this option.
fix: remove fake no_dead_strip for osx
Closes https://github.com/rust-lang/rust/issues/99788
Link arg `-no_dead_strip` doesn't exist on OSX at all.
The `no_gc_sections` function was never called before export-executable-symols implementation, and `export-executable-symbols` still works, so we just remove it.
r? `@bjorn3`
Use line numbers relative to the function in mir-opt tests
As shown in #99770, the line numbers can be a big source of needless and confusing diffs. This PR adds a new flag `-Zmir-pretty-relative-line-numbers` to make them relative to the function declaration, which avoids most needless diffs from attribute changes.
`@JakobDegen` told me that there has been a zulip conversation about disabling line numbers with mixed opinions, so I'd like to get some feedback here, for this hopefully better solution.
r? rust-lang/wg-mir-opt
This avoids monomorphizing all linker code for each codegen backend and
will allow passing in extra information to the archive builder from the
codegen backend.
This initial implementation handles transmutations between types with specified layouts, except when references are involved.
Co-authored-by: Igor null <m1el.2027@gmail.com>
lint: add bad opt access internal lint
Prompted by [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sess.2Ecrate_types.28.29.20vs.20sess.2Eopts.2Ecrate_types/near/290682847).
Some command-line options accessible through `sess.opts` are best accessed through wrapper functions on `Session`, `TyCtxt` or otherwise, rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed through a wrapper function so that this is prohibited. Options are annotated with a new attribute `rustc_lint_opt_deny_field_access` which can specify the error message (i.e. "use this other function instead") to be emitted.
A simpler alternative would be to simply rename the options in the option type so that it is clear they should not be used, however this doesn't prevent uses, just discourages them. Another alternative would be to make the option fields private, and adding accessor functions on the option types, however the wrapper functions sometimes rely on additional state from `Session` or `TyCtxt` which wouldn't be available in an function on the option type, so the accessor would simply make the field available and its use would be discouraged too.
**Leave a comment if there's an option I should add this to.**
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes#99641
Remove let-chain close brace check.
#98633 added some checks to forbid let-expressions that aren't in a let chain. This check looks at the preceding token to determine if it is a valid let-chain position. One of those tokens it checks is the close brace `}`. However, to my understanding, it is not possible for a let chain to be preceded by a close brace. This PR removes the check to avoid any confusion.
This is a followup to the discussion at https://github.com/rust-lang/rust/pull/98633#pullrequestreview-1030962803. It wasn't clear what issues the original PR ran into, but I have run the full set of CI tests and nothing failed. I also can't conceive of a situation where this would be possible. This doesn't reject any valid code, I'm just removing it to avoid confusion to anyone looking at this code in the future.
Replace the separate AbortCodegenOnDrop guard by integrating this
functionality into OngoingCodegen (or rather, the Coordinator part
of it). This ensures that we send a CodegenAborted message and
wait for workers to finish even if the panic occurs outside
codegen_crate() (e.g. inside join_codegen()).
This requires some minor changes to the handling of CodegenAborted,
as it can now occur when the main thread is LLVMing rather than
Codegenning.
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.
A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.
Signed-off-by: David Wood <david.wood@huawei.com>
If an internal lint uses `typeck_results` or similar queries then that
can result in rustdoc checking code that it shouldn't (e.g. from other
platforms) and emit compilation errors.
Signed-off-by: David Wood <david.wood@huawei.com>
Sync rustc_codegen_cranelift
I did a large refactoring of the intrinsics module to remove the intrinsic_match macro which is not very clear to other people. This also enables rustfmt to run on this code. While I already did a sync yesterday, I am going to do another sync again to avoid potential conflicts as those will likely be painful to resolve.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Check that RPITs constrained by a recursive call in a closure are compatible
Fixes#99073
Adapts a similar visitor pattern to `find_opaque_ty_constraints` (that we use to check TAITs), but with some changes:
0. Only walk the "OnlyBody" children, instead of all items in the RPIT's defining scope
1. Only walk through the body's children if we found a constraining usage
2. Don't actually do any inference, just do a comparison and error if they're mismatched
----
r? `@oli-obk` -- you know all this impl-trait stuff best... is this the right approach? I can explain the underlying issue better if you'd like, in case that might reveal a better solution. Not sure if it's possible to gather up the closure's defining usages of the RPIT while borrowck'ing the outer function, that might be a better place to put this check...
Add a brief comment explaining why the diagnostic migration lints aren't
included in the `rustc::internal` diagnostic group.
Signed-off-by: David Wood <david.wood@huawei.com>
passes: port more of `check_attr` module
Continues from #99213.
Port more diagnostics in `rustc_passes::check_attr` to using the diagnostic derive and translation machinery.
r? `@compiler-errors`
Prefer visibility map parents that are not `doc(hidden)` first
Far simpler approach to #98876.
This only fixes the case where the parent is `doc(hidden)`, not where the child is `doc(hidden)` since I don't know how to get the attrs on the import statement given a `ModChild`... I'll try to follow up with that, but this is a good first step.
codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
r? `@nikic`
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
While we're here, we also emit allocator attributes on
__rust_alloc_zeroed. This should allow LLVM to perform more
optimizations for zeroed blocks, and probably fixes#90032. [This
comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157)
mentions "weird UB-like behaviour with bitvec iterators in
rustc_data_structures" so we may need to back this change out if things
go wrong.
The new test cases require LLVM 15, so we copy them into LLVM
14-supporting versions, which we can delete when we drop LLVM 14.
This attribute allows to mark default body of a trait function as
unstable. This means that implementing the trait without implementing
the function will require enabling unstable feature.
This is useful in conjunction with `#[rustc_must_implement_one_of]`,
we may want to relax requirements for a trait, for example allowing
implementing either of `PartialEq::{eq, ne}`, but do so in a safe way
-- making implementation of only `PartialEq::ne` unstable.
Rollup of 5 pull requests
Successful merges:
- #99618 (handle consts with param/infer in `const_eval_resolve` better)
- #99666 (Restore `Opaque` behavior to coherence check)
- #99692 (interpret, ptr_offset_from: refactor and test too-far-apart check)
- #99739 (Remove erroneous E0133 code from an error message.)
- #99748 (Use full type name instead of just saying `impl Trait` in "captures lifetime" error)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use full type name instead of just saying `impl Trait` in "captures lifetime" error
I think this is very useful, especially when there's >1 `impl Trait`, and it just means passing around a bit more info that we already have access to.
Remove erroneous E0133 code from an error message.
This error message is about `derive` and `packed`, but E0133 is for
"Unsafe code was used outside of an unsafe function or block".
r? ``@estebank``
interpret, ptr_offset_from: refactor and test too-far-apart check
We didn't have any tests for the "too far apart" message, and indeed that check mostly relied on the in-bounds check and was otherwise probably not entirely correct... so I rewrote that check, and it is before the in-bounds check so we can test it separately.
Restore `Opaque` behavior to coherence check
Fixes#99663.
This broke in 84c3fcd2a0. I'm not exactly certain that adding this behavior back is necessarily correct, but at least the UI test I provided may stimulate some thoughts.
I think delaying a bug here is certainly not correct in the case of opaques -- if we want to change coherence behavior for opaques, then we should at least be emitting a new error.
r? ``@lcnr``
handle consts with param/infer in `const_eval_resolve` better
This PR addresses [this thread here](https://github.com/rust-lang/rust/pull/99449#discussion_r924141230). Was this the change you were looking for ``@lcnr?``
Interestingly, one test has begun to pass. Was that expected?
r? ``@lcnr``
Sync rustc_codegen_cranelift
This time most of the changes are bugfixes. No exciting new features to report. Thanks `@matthiaskrgr` for reporting a bunch of crashes!
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Remove reachable coverage without counters
Remove reachable coverage without counters to maintain invariant that
either there is no coverage at all or there is a live coverage counter
left that provides the function source hash.
The motivating example would be a following closure:
```rust
let f = |x: bool| {
debug_assert!(x);
};
```
Which, with span changes from #93967, with disabled debug assertions,
after the final CFG simplifications but before removal of dead blocks,
gives rise to MIR:
```rust
fn main::{closure#0}(_1: &[closure@a.rs:2:13: 2:22], _2: bool) -> () {
debug x => _2;
let mut _0: ();
bb0: {
Coverage::Expression(4294967295) = 1 - 2;
return;
}
...
}
```
Which also makes the initial instrumentation quite suspect, although
this pull request doesn't attempt to address that aspect directly.
Fixes#98833.
r? ``@wesleywiser`` ``@richkadel``
Remove some explicit `self.infcx` for `FnCtxt`, which already derefs into `InferCtxt`
The use of `self.infcx.method_on_infcx` vs `self.method_on_infcx` when `self` is a `FnCtxt` is a bit inconsistent, so I'm moving some `self.infcx` usages I found to just use autoderef
Slightly improve mismatched GAT where clause error
This makes the error reporting a bit more standardized between `where` on GATs and functions.
cc #99206 (`@BoxyUwU),` don't want to mark this as as "fixed" because they're still not perfect, but this is still an improvement IMO so I want to land it incrementally.
regarding "consider adding where clause to trait definition", we don't actually do that for methods as far as i can tell? i could file an issue to look into that maybe.
Enable raw-dylib for bin crates
Fixes#93842
When `raw-dylib` is used in a `bin` crate, we need to collect all of the `raw-dylib` functions, generate the import library and add that to the linker command line.
I also changed the tests so that 1) the C++ dlls are created after the Rust dlls, thus there is no chance of accidentally using them in the Rust linking process and 2) disabled generating import libraries when building with MSVC.
Rollup of 9 pull requests
Successful merges:
- #92390 (Constify a few `(Partial)Ord` impls)
- #97077 (Simplify some code that depend on Deref)
- #98710 (correct the output of a `capacity` method example)
- #99084 (clarify how write_bytes can lead to UB due to invalid values)
- #99178 (Lighten up const_prop_lint, reusing const_prop)
- #99673 (don't ICE on invalid dyn calls)
- #99703 (Expose size_hint() for TokenStream's iterator)
- #99709 (`Inherited` always has `TypeckResults` available)
- #99713 (Fix sidebar background)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Simplify some code that depend on Deref
Now that we can assume #97025 works, it's safe to expect Deref is always in the first place of projections. With this, I was able to simplify some code that depended on Deref's place in projections. When we are able to move Derefer before `ElaborateDrops` successfully we will be able to optimize more places.
r? `@oli-obk`
Resolve function lifetime elision on the AST
~Based on https://github.com/rust-lang/rust/pull/97720~
Lifetime elision for functions is purely syntactic in nature, so can be resolved on the AST.
This PR replicates the elision logic and diagnostics on the AST, and replaces HIR-based resolution by a `delay_span_bug`.
This refactor allows for more consistent diagnostics, which don't have to guess the original code from HIR.
r? `@petrochenkov`
