Add `explicit_extern_abis` Feature and Enforce Explicit ABIs
The unstable `explicit_extern_abis` feature is introduced, requiring explicit ABIs in `extern` blocks. Hard errors will be enforced with this feature enabled in a future edition.
RFC rust-lang/rfcs#3722
Update #134986
fix for multiple `#[repr(align(N))]` on functions
tracking issue: https://github.com/rust-lang/rust/issues/82232
fixes https://github.com/rust-lang/rust/issues/132464
The behavior of align is specified at https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.alignment.align
> For align, if the specified alignment is less than the alignment of the type without the align modifier, then the alignment is unaffected.
So in effect that means that the maximum of the specified alignments should be chosen. That is also the current behavior for `align` on ADTs:
```rust
#![feature(fn_align)]
#[repr(C, align(32), align(64))]
struct Foo {
x: u64,
}
const _: () = assert!(core::mem::align_of::<Foo>() == 64);
// See the godbolt LLVM output: the alignment of this function is 32
#[no_mangle]
#[repr(align(32))]
#[repr(align(64))]
fn foo() {}
// The current logic just picks the first alignment: the alignment of this function is 64
#[no_mangle]
#[repr(align(64))]
#[repr(align(32))]
fn bar() {}
```
https://godbolt.org/z/scco435jEafa859f812/compiler/rustc_middle/src/ty/mod.rs (L1529-L1532)
The https://github.com/rust-lang/rust/issues/132464 issue is really about parsing/representing the attribute, which has already been improved and now uses the "parse, don't validate" attribute approach. That means the behavior is already different from what the issue describes: on current `main`, the first value is chosen. This PR fixes a logic error, where we just did not check for the effect of two or more `align` modifiers. In combination, that fixes the issue.
cc ``@jdonszelmann`` if you do have further thoughs here
parser: Remove old diagnostic notes for type ascription syntax
Type ascription syntax was removed by #109128 in 2023, so “remove this again in a few months” is long overdue.
Happily, this also reduces the amount of parser diagnostic code that cares whether the compiler is unstable.
---
See also the recent #138898, which removed some other related dead code but declined to touch the diagnostics.
It's possible that some of these parser tests are no longer useful at all, but I haven't investigated them for this PR.
Include optional dso_local marker for functions in `enum-match.rs`
This PR adds the `dso_local` marker to the `enum-match.rs` test annotations for all the `match\d+` functions. These markers are added by LLVM when targeting `aarch64-unknown-none` even though they are missing in `aarch64-unknown-linux-gnu`. This is causing a CI error when running the codegen suite on the `aarch64-unknown-none` target for ferrocene.
r? ``@scottmcm``
hygiene: Rename semi-transparent to semi-opaque
"Semi-transparent" is just too damn long for a name, especially when used multiple times on a single line, it bothered me when working on #139083.
An optimist sees a macro as semi-opaque, a pessimist sees it as semi-transparent.
Or is it the other way round?
Add minimal x86_64-lynx-lynxos178 support.
Add minimal x86_64-lynx-lynxos178 support. It's possible to build no_std
programs with this compiler.
## Tier 3 Target Policy
> 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. (The
mechanism to track and CC such developers may evolve over time.)
Tim Newsome (`@tnewsome-lynx)` will be the designated developer for
x86_64-lynx-lynxos178 support.
> Targets must use naming consistent with any existing targets; for instance, a
target for the same CPU or OS as an existing Rust target should use the same
name for that CPU or OS. Targets should normally use the same names and naming
conventions as used elsewhere in the broader ecosystem beyond Rust (such as in
other toolchains), unless they have a very good reason to diverge. Changing the
name of a target can be highly disruptive, especially once the target reaches a
higher tier, so getting the name right is important even for a tier 3 target.
I believe the target is named appropriately.
> Target names should not introduce undue confusion or ambiguity unless
absolutely necessary to maintain ecosystem compatibility. For example, if the
name of the target makes people extremely likely to form incorrect beliefs about
what it targets, the name should be changed or augmented to disambiguate it.
The target name is not confusing.
> If possible, use only letters, numbers, dashes and underscores for the name.
Periods (.) are known to cause issues in Cargo.
Done.
> 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.
> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license
(MIT OR Apache-2.0).
All this new code is licensed under the Apache-2.0 license.
> 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. This applies whether
the dependency is a Rust crate that would require adding new license exceptions
(as specified by the tidy tool in the rust-lang/rust repository), or whether the
dependency is a native library or binary. In other words, the introduction of
the target must not cause a user installing or running a version of Rust or the
Rust tools to be subject to any new license requirements.
Done.
> 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. Host tools
built for the target itself may depend on the ordinary runtime libraries
supplied by the platform and commonly used by other applications built for the
target, but those libraries must not be required for code generation for the
target; cross-compilation to the target must not require such libraries at all.
For instance, rustc built for the target may depend on a common proprietary C
runtime library or console output library, but must not depend on a proprietary
code generation library or code optimization library. Rust's license permits
such combinations, but the Rust project has no interest in maintaining such
combinations within the scope of Rust itself, even at tier 3.
I think we're in the clear here. We do link against some static libraries that
are proprietary (like libm and libc), but those are not used to generate code.
E.g. the VxWorks target requires `wr-c++` to be installed, which is not
publically available.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous"
legal/licensing terms include but are not limited to: non-disclosure
requirements, non-compete requirements, contributor license agreements (CLAs) or
equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional
on the employer or employment of any particular Rust developers, revocable
terms, any requirements that create liability for the Rust project or its
developers or users, or any requirements that adversely affect the livelihood or
prospects of the Rust project or its developers or users.
Our intention is to allow anyone with access to LynxOS CDK to use Rust for it.
> Neither this policy nor any decisions made regarding targets shall create any
binding agreement or estoppel by any party. If any member of an approving Rust
team serves as one of the maintainers of a target, or has any legal or
employment requirement (explicit or implicit) that might affect their decisions
regarding a target, they must recuse themselves from any approval decisions
regarding the target's tier status, though they may otherwise participate in
discussions.
> This requirement does not prevent part or all of this policy from being cited
in an explicit contract or work agreement (e.g. to implement or maintain support
for a target). This requirement exists to ensure that a developer or team
responsible for reviewing and approving a target does not face any legal threats
or obligations that would prevent them from freely exercising their judgment in
such approval, even if such judgment involves subjective matters or goes beyond
the letter of these requirements.
No problem.
> Tier 3 targets should attempt to implement as much of the standard libraries
as possible and appropriate (core for most targets, alloc for targets that can
support dynamic memory allocation, std for targets with an operating system or
equivalent layer of system-provided functionality), but may leave some code
unimplemented (either unavailable or stubbed out as appropriate), whether
because the target makes it impossible to implement or challenging to implement.
The authors of pull requests are not obligated to avoid calling any portions of
the standard library on the basis of a tier 3 target not implementing those
portions.
With this first PR, only core is supported. I am working on support for the std
library and intend to submit that once all the tests are passing.
> The target must provide documentation for the Rust community explaining how to
build for the target, using cross-compilation if possible. If the target
supports running binaries, or running tests (even if they do not pass), the
documentation must explain how to run such binaries or tests for the target,
using emulation if possible or dedicated hardware if necessary.
This is documented in `src/doc/rustc/src/platform-support/lynxos178.md`.
> Tier 3 targets must not impose burden on the authors of pull requests, or
other developers in the community, to maintain the target. In particular, do not
post comments (automated or manual) on a PR that derail or suggest a block on
the PR based on a tier 3 target. Do not send automated messages or notifications
(via any medium, including via `@)` to a PR author or others involved with a PR
regarding a tier 3 target, unless they have opted into such messages.
> Backlinks such as those generated by the issue/PR tracker when linking to an
issue or PR are not considered a violation of this policy, within reason.
However, such messages (even on a separate repository) must not generate
notifications to anyone involved with a PR who has not requested such
notifications.
Understood.
> 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.
> In particular, this may come up when working on closely related targets, such
as variations of the same architecture with different features. Avoid
introducing unconditional uses of features that another variation of the target
may not have; use conditional compilation or runtime detection, as appropriate,
to let each target run code supported by that target.
As far as I know this change does not affect any other targets.
> Tier 3 targets must be able to produce assembly using at least one of rustc's
supported backends from any host target. (Having support in a fork of the
backend is not sufficient, it must be upstream.)
Many targets produce assembly for x86_64 so that also works for LynxOS-178.
Add test for issue 125668
closes: #125668
The issue stemmed from improper handling of const {} blocks used in array length expressions. As of rustc 1.80.0-nightly (804421dff 2024-06-07), this ICE no longer occurs and the code compiles successfully 😀
Don't compute name of associated item if it's an RPITIT
Use `Option::then` in favor of `Option::then_some` to not compute `AssocItem::name` if it fails the condition. Alternatively, I'd be open to changing this just to an `if`.
Fixes https://github.com/rust-lang/rust/issues/139873
r? ```@nnethercote```
Stabilize `-Zdwarf-version` as `-Cdwarf-version`
I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future.
# `-Zdwarf-version` stabilization report
## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
No RFC/MCP, this flag was added in https://github.com/rust-lang/rust/pull/98350 and was not deemed large enough to require additional process.
The tracking issue for this feature is #103057.
## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
None that has been extensively debated but there are a few questions that could have been chosen differently:
1. What should the flag name be?
The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do?
2. What is the behavior when flag is used on targets that do not support DWARF?
Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs).
3. Does the precompiled standard library potentially using a different version of DWARF a problem?
I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries.
## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.
No extensions per se, although future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted.
## Summarize the major parts of the implementation and provide links into the code (or to PRs)
- Targets define their preferred or default DWARF version: 34a5ea911c/compiler/rustc_target/src/spec/mod.rs (L2369)
- We use the target default but this can be overriden by `-{C,Z} dwarf-version` 34a5ea911c/compiler/rustc_session/src/session.rs (L738)
- The flag is validated 34a5ea911c/compiler/rustc_session/src/session.rs (L1253-L1258)
- When debuginfo is generated, we tell LLVM to use the requested value or the target default 34a5ea911c/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs (L106)
## Summarize existing test coverage of this feature
- Test that we actually generate the appropriate DWARF version
- https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf5.rs
- https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf4.rs
- Test that LTO with different DWARF versions picks the highest version
- https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs
- Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error
- https://github.com/rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs
- Ensure LLVM does not report a warning when LTO'ing different DWARF versions together
- https://github.com/rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs
## Has a call-for-testing period been conducted? If so, what feedback was received?
No call-for-testing has been conducted but Rust for Linux has been using this flag without issue.
## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
All reported bugs have been resolved.
## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- Initial implementation in https://github.com/rust-lang/rust/pull/98350 by `@pcwalton`
- Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in https://github.com/rust-lang/rust/pull/117962 by `@weihanglo.`
- Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#136746) by `@wesleywiser`
## What FIXMEs are still in the code for that feature and why is it ok to leave them there?
No FIXMEs related to this feature.
## What static checks are done that are needed to prevent undefined behavior?
This feature cannot cause undefined behavior.
We ensure the DWARF version is one of the supported values [here](34a5ea911c/compiler/rustc_session/src/session.rs (L1255-L1257)).
## In what way does this feature interact with the reference/specification, and are those edits prepared?
No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the stabilization PR.
## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
## What other unstable features may be exposed by this feature?
`-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate.
## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?
No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup.
Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors.
cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (https://github.com/rust-lang/cc-rs/pull/1395).
---
Closes#103057
`#[target_feature]` attributes refer to a target-specific list of
features. Enabling certain features can imply enabling other features.
Certain features are always enabled on certain targets, since they are
required by the target's ABI. Features can also be enabled indirectly
based on other compiler flags.
Feature information is ultimately known to `rustc`. Rather than force
external tools to track it -- which may be wildly impractical due to
`-C target-cpu` -- have `rustdoc` output `rustc`'s feature data.
This commit adds unprivileged ratified extensions that are either
dicoverable from the `riscv_hwprobe` syscall of the Linux kernel (as of
version 6.14) plus 1 minus 3 extensions.
Plus 1:
* "B"
This is a combination of "Zba", "Zbb" and "Zbs".
Note:
Although not required by the RISC-V specification, it is convenient to
imply "B" from its three members (will be implemented in LLVM 21/22) but
this is not yet implemented in Rust due to current implication handling.
It still implies three members *from* "B".
Minus 2:
* "Zcf" (target_arch = "riscv32" only)
This is the compression instruction subset corresponding "F".
This is implied from RV32 + "C" + "F" but this complex handling is
not yet supported by Rust's feature handling.
* "Zcd"
This is the compression instruction subset corresponding "D".
This is implied from "C" + "D" but this complex handling is
not yet supported by Rust's feature handling.
* "Supm"
Unlike regular RISC-V extensions, "Supm" and "Sspm" extensions do not
provide any specific architectural features / constraints but requires
*some* mechanisms to control pointer masking for the current mode.
For instance, reported existence of the "Supm" extension in Linux means
that `prctl` system call to control pointer masking is available and
there are alternative ways to detect the existence.
Notes:
* Because this commit adds the "Zca" extension (an integer subset of the
"C" extension), the "C" extension is modified to imply "Zca".
Normalize ADT field in `find_tails_for_unsizing`
See the comment inline and in the test.
TL;DR is that we're getting getting a type from a `type_of` query and then matching on it structurally in codegen, so we're obligated to normalize it. The fact that this wasn't triggered earlier is that all of the types that have `CoerceUnsized` implementations never encounter aliases when peeling the ADT down to their base reference/ptr type.
**NOTE**: I also renamed some things and reorganized the function a bit.
Fixes#139812Fixes#74451, which I didn't think was interesting enough to add another test.
r? oli-obk
Namely, use a more sensical primary span.
Don't pretty-print AST nodes for the diagnostic message. Why:
* It's lossy (e.g., it doesn't replicate trailing `+`s in trait objects.
* It's prone to leak error nodes (printed as `(/*ERROR*/)`) since
the LHS can easily represent recovered code (e.g., `fn(i32?) + T`).
Let CStrings be either 1 or 2 byte aligned.
We see a regression on the `tests/assembly/cstring-merging.rs` test on s390x.
Some architectures (like s390x) require strings to be 2 byte aligned. Therefor the section name will be marked with a .2 postfix on this architectures.
Allowing a section name with a .1 or .2 postfix will make the test pass on either platform.
Overhaul `AssocItem`
`AssocItem` has multiple fields that only make sense some of the time. E.g. the `name` can be empty if it's an RPITIT associated type. It's clearer and less error prone if these fields are moved to the relevant `kind` variants.
r? ``@fee1-dead``
Allow const patterns of matches to contain pattern types
Trying to pattern match on a type containing a pattern type will currently fail with an ICE
```rust
error: internal compiler error: compiler/rustc_mir_build/src/builder/matches/test.rs:459:18: invalid type for non-scalar compare: (u32) is 1..
--> src/main.rs:22:5
|
22 | TWO => {}
| ^^^
```
because the compiler tries to generate a MIR `BinOp(Eq)` operation on a pattern type, which is not supported. While we could support that, there are side effects of allowing this (none that would compile, but the compiler would simultaneously think it could `==` pattern types and that it could not because `PartialEq` is not implemented. So instead I change the logic for pattern matching to transmute pattern types to their base type before comparing.
r? ```@BoxyUwU```
cc #123646 ```@scottmcm``` ```@joshtriplett```
Enable contracts for const functions
Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions.
This commit also removes one level of indirection for ensures clauses since we no longer build a closure around the ensures predicate.
Resolves#136925
**Call-out:** This is still a draft PR since CI is broken due to a new warning message for unreachable code when the bottom of the function is indeed unreachable. It's not clear to me why the warning wasn't triggered before.
r? ```@compiler-errors```
