Automatic Rustup #4277
Merged
Automatic Rustup #4277
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
0.8.7 can trigger a panic when debug assertions are enabled when used via flate2 in some cases
Bump `FileEncoder` buffer size to 64 kB This helps avoid file system overhead on Windows. The improvement are probably reduced a bit on other platforms. Making the buffer size even larger does further improve performance, but that increase memory use further. <table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th><td align="right">Physical Memory</td><td align="right">Physical Memory</td><td align="right">%</th><td align="right">Committed Memory</td><td align="right">Committed Memory</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.3336s</td><td align="right">0.3242s</td><td align="right">💚 -2.82%</td><td align="right">96.97 MiB</td><td align="right">97.12 MiB</td><td align="right"> 0.16%</td><td align="right">167.87 MiB</td><td align="right">167.97 MiB</td><td align="right"> 0.06%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1331s</td><td align="right">0.1307s</td><td align="right">💚 -1.79%</td><td align="right">61.92 MiB</td><td align="right">62.05 MiB</td><td align="right"> 0.20%</td><td align="right">124.66 MiB</td><td align="right">124.74 MiB</td><td align="right"> 0.06%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.2485s</td><td align="right">0.2399s</td><td align="right">💚 -3.45%</td><td align="right">78.32 MiB</td><td align="right">78.55 MiB</td><td align="right"> 0.29%</td><td align="right">145.22 MiB</td><td align="right">145.45 MiB</td><td align="right"> 0.15%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.5321s</td><td align="right">0.5175s</td><td align="right">💚 -2.76%</td><td align="right">118.58 MiB</td><td align="right">118.77 MiB</td><td align="right"> 0.16%</td><td align="right">192.99 MiB</td><td align="right">193.17 MiB</td><td align="right"> 0.09%</td></tr><tr><td>Total</td><td align="right">1.2474s</td><td align="right">1.2123s</td><td align="right">💚 -2.81%</td><td align="right">355.78 MiB</td><td align="right">356.49 MiB</td><td align="right"> 0.20%</td><td align="right">630.74 MiB</td><td align="right">631.32 MiB</td><td align="right"> 0.09%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9729s</td><td align="right">💚 -2.71%</td><td align="right">1 byte</td><td align="right">1.00 bytes</td><td align="right"> 0.20%</td><td align="right">1 byte</td><td align="right">1.00 bytes</td><td align="right"> 0.09%</td></tr></table>
Use the chaining methods on PartialOrd for slices too #138135 added these doc-hidden trait methods to improve the tuple codegen. This PR adds more implementations and callers so that the codegen for slice (and array) comparisons also improves.
std: Fix build for NuttX targets Fix std build for all NuttX targets. It is the single largest set of failures on <https://does-it-build.noratrieb.dev/>. Although, ESP-IDF also requires these same gates, there are other issues for those targets. This can verified be running `x check library/std --target=` for all NuttX targets. cc ``@no1wudi``
…lacrum Use -C target-cpu=z13 on s390x vector test currently we see a regression in the `dont-shuffle-bswaps.rs` on s390x. This is due to, the default s390x cpu is set to z10 [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9) which does not have vector instructions implemented. To make the test pass we need to create an extra test revision and set target-cpu at least to `z13`.
libtest: Pass the test's panic payload as Option instead of Result Passing a `Result<(), &dyn Any>` to `calc_result` requires awkward code at both call sites to build a fake result, for no real benefit. It's much easier to just pass the payload as `Option<&dyn Any>`. No functional change.
…ulacrum update ```miniz_oxide``` to 0.8.8 I would normally let the auto actions handle this but it turns out 0.8.7 can trigger a panic when debug assertions are enabled in a few cases so I feel it's important it gets sorted more quickly. (and I would ideally like to yank that version but was worried that could cause some issues had been pulled in as a dependency by this repo already before I discovered the problem) As it can only happen when debug assertions are enabled (the overflow results in the intended result so it doesn't cause any issue in release mode) and using the wrapping buffer mode when decompressing it is very unlikely to cause any issues here but I would like to get it sorted just to be safe. ```miniz_oxide``` is used in the standard library (and some tools) via ```backtrace-rs ``` which doesn't use a wrapping buffer, and thus won't trigger this condition. There does however seem like there are some tools that do dependency on ```flate2``` which does use ```miniz_oxide``` decompression using a a wrapping buffer and could in theory trigger it if they are run when compiled with debug assertions enabled. It's kinda unclear what version what tool uses though as several of them specify older versions of flate2 which depended on ```miniz_oxide``` 0.7.x in cargo.toml, and ```miniz_oxide```, and not all have a cargo.lock and due to an older version of ```backtrace``` being in the root Cargo.lock which still depended on ```miniz_oxide``` 0.7.4, so that version is also pulled in alongside the newer version.
compiletest: Make `SUGGESTION` annotations viral If one of them is expected in a test file, then others should be annotated as well, in the same way as with `HELP`s and `NOTE`s. This doesn't require much of an additional annotation burden, but simplifies the rules. r? ```@jieyouxu```
…=kobzol Fix profiler_builtins build script to handle full path to profiler lib LLVM_PROFILER_RT_LIB may be set to an absolute path (e.g., in Fedora builds), but `-l` expects a library name, not a path. After #138273, this caused builds to fail with a "could not find native static library" error. This patch updates the build script to split the path into directory and filename, using `cargo::rustc-link-search` for the directory and `cargo::rustc-link-lib=+verbatim` for the file. This allows profiler_builtins to correctly link the static library even when an absolute path is provided.
…,joboet Use `with_native_path` for Windows Ideally, each platform should use their own native path type internally. This will, for example, allow passing a UTF-16 string directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated wide string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this just does some of the Windows parts. As with the previous Unix PR (#138832) this is intended to be merely a refactoring so I've avoided anything that may require more substantial changes.
Move `args` into `std::sys` Move platform definitions of `args` into `std::sys`, as part of rust-lang/rust#117276. cc ``@joboet``
End all lines in src/stage0 with trailing newline Most tools that process text files prefer if every line ends in \n. Text files without the last newline are aberrant and usually not what you want. **Before:** ```console $ cat src/stage0 src/stage0 dist_server=https://static.rust-lang.org artifacts_server=https://ci-artifacts.rust-lang.org/rustc-builds ... dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.gz=986f6c594d37bcbd3833e053640ba8775f68d26a65c5618386654ef55d7b3542 dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.xz=c0d9a88c30d2ab38ec3a11fabb5515ed9bc3ac1a8e35a438d68bf7ff82f6b843dist_server=https://static.rust-lang.org artifacts_server=https://ci-artifacts.rust-lang.org/rustc-builds ... dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.gz=986f6c594d37bcbd3833e053640ba8775f68d26a65c5618386654ef55d7b3542 dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.xz=c0d9a88c30d2ab38ec3a11fabb5515ed9bc3ac1a8e35a438d68bf7ff82f6b843$ ▌ ``` **After:** ```console $ cat src/stage0 src/stage0 dist_server=https://static.rust-lang.org artifacts_server=https://ci-artifacts.rust-lang.org/rustc-builds ... dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.gz=986f6c594d37bcbd3833e053640ba8775f68d26a65c5618386654ef55d7b3542 dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.xz=c0d9a88c30d2ab38ec3a11fabb5515ed9bc3ac1a8e35a438d68bf7ff82f6b843 dist_server=https://static.rust-lang.org artifacts_server=https://ci-artifacts.rust-lang.org/rustc-builds ... dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.gz=986f6c594d37bcbd3833e053640ba8775f68d26a65c5618386654ef55d7b3542 dist/2025-04-02/rustc-nightly-x86_64-unknown-netbsd.tar.xz=c0d9a88c30d2ab38ec3a11fabb5515ed9bc3ac1a8e35a438d68bf7ff82f6b843 $ ▌ ```
Move `select_unpredictable` to the `hint` module There has been considerable discussion in both the ACP (rust-lang/libs-team#468) and tracking issue (#133962) about whether the `bool::select_unpredictable` method should be in `core::hint` instead. I believe this is the right move for the following reasons: - The documentation explicitly says that it is a hint, not a codegen guarantee. - `bool` doesn't have a corresponding `select` method, and I don't think we should be adding one. - This shouldn't be something that people reach for with auto-completion unless they specifically understand the interactions with branch prediction. Using conditional moves can easily make code *slower* by preventing the CPU from speculating past the condition due to the data dependency. - Although currently `core::hint` only contains no-ops, this isn't a hard rule (for example `unreachable_unchecked` is a bit of a gray area). The documentation only status that the module contains "hints to compiler that affects how code should be emitted or optimized". This is consistent with what `select_unpredictable` does.
Rollup of 10 pull requests Successful merges: - #138972 (std: Fix build for NuttX targets) - #139177 (Use -C target-cpu=z13 on s390x vector test) - #139511 (libtest: Pass the test's panic payload as Option instead of Result) - #139605 (update ```miniz_oxide``` to 0.8.8) - #139618 (compiletest: Make `SUGGESTION` annotations viral) - #139677 (Fix profiler_builtins build script to handle full path to profiler lib) - #139683 (Use `with_native_path` for Windows) - #139710 (Move `args` into `std::sys`) - #139721 (End all lines in src/stage0 with trailing newline) - #139726 (Move `select_unpredictable` to the `hint` module) r? `@ghost` `@rustbot` modify labels: rollup
…rpolated, r=petrochenkov Remove `Nonterminal` and `TokenKind::Interpolated` A third attempt at this; the first attempt was #96724 and the second was #114647. r? `@ghost`
don't store opaque info during encoding Now `remapped_ctxts` reserved and let's check the performance. r? `@petrochenkov`
re-use `Sized` fast-path There's an existing fast path for the `type_op_prove_predicate` predicate, checking for trivially `Sized` types, which can be re-used when evaluating obligations within queries. This should improve performance and was found to be beneficial in #137944. r? types
Avoid unused clones in `Cloned<I>` and `Copied<I>` Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`. r? libs-api
opt-dist: use executable-extension for host llvm-profdata because it's used for target llvm-profdata too r? Kobzol
Add test for issue 34834
closes: #34834
This PR adds a UI test for a case where a trait with an associated type using a higher-ranked trait bound (HRTB) failed to compile in Rust 1.55.0 but succeeded starting from 1.56.0.
```rust
pub trait Provides<'a> {
type Item;
}
pub trait Selector: for<'a> Provides<'a> {
type Namespace: PartialEq + for<'a> PartialEq<<Self as Provides<'a>>::Item>;
fn get_namespace(&self) -> <Self as Provides>::Item;
}
pub struct MySelector;
impl<'a> Provides<'a> for MySelector {
type Item = &'a str;
}
impl Selector for MySelector {
type Namespace = String;
fn get_namespace(&self) -> &str {
unimplemented!()
}
}
fn main() {}
```
* ❌ [compile fail (rustc: 1.55.0)](https://godbolt.org/z/T1jY1Ebo6)
* ⭕ [compile pass (rustc: 1.56.0)](https://godbolt.org/z/e4jo11Ma7)
Miri subtree update r? `@ghost` Fixes build failures on macOS
Rollup of 8 pull requests Successful merges: - #139745 (Avoid unused clones in `Cloned<I>` and `Copied<I>`) - #139757 (opt-dist: use executable-extension for host llvm-profdata) - #139778 (Add test for issue 34834) - #139783 (Use `compiletest-ignore-dir` for bootstrap self-tests) - #139797 (Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it) - #139799 (Specify `--print info=file` syntax in `--help`) - #139811 (Use `newtype_index!`-generated types more idiomatically) - #139813 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
…piler-errors,oli-obk,RalfJung 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```
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```
std: sys: process: uefi: Use NULL stdin by default According to the docs in `Command::output`: > By default, stdout and stderr are captured (and used to provide the resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing. This was being violated by UEFI which was inheriting stdin by default. While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL. UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin. One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route. Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error. cc ```@nicholasbishop``` ```@dvdhrm```
std: add Output::exit_ok approved in ACP rust-lang/libs-team#554 Tracking issue: rust-lang/rust#84908
Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file}
Simplification/redesign of the unstable proc macro span API, tracked in rust-lang/rust#54725:
Before:
```rust
impl Span {
pub fn line(&self) -> usize;
pub fn column(&self) -> usize;
pub fn source_file(&self) -> SourceFile;
}
#[derive(Clone, Debug, PartialEq, Eq)]
pub struct SourceFile { .. }
impl !Send for SourceFile {}
impl !Sync for SourceFile {}
impl SourceFile {
pub fn path(&self) -> PathBuf;
pub fn is_real(&self) -> bool;
}
```
After:
```rust
impl Span {
pub fn line(&self) -> usize;
pub fn column(&self) -> usize;
pub fn file(&self) -> String; // Mapped file name, for display purposes.
pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on disk.
}
```
This resolves the last blocker for stabilizing these methods. (Stabilizing will be a separate PR with FCP.)
std/thread: Use default stack size from menuconfig for NuttX * Update comments to clarify the usage of zero as an indication for default stack size configuration * Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform This change improves clarity and consistency in stack size configuration across platforms.
Rollup of 17 pull requests
Successful merges:
- #138374 (Enable contracts for const functions)
- #138380 (ci: add runners for vanilla LLVM 20)
- #138393 (Allow const patterns of matches to contain pattern types)
- #139517 (std: sys: process: uefi: Use NULL stdin by default)
- #139554 (std: add Output::exit_ok)
- #139660 (compiletest: Add an experimental new executor to replace libtest)
- #139669 (Overhaul `AssocItem`)
- #139671 (Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file})
- #139750 (std/thread: Use default stack size from menuconfig for NuttX)
- #139772 (Remove `hir::Map`)
- #139785 (Let CStrings be either 1 or 2 byte aligned.)
- #139789 (do not unnecessarily leak auto traits in item bounds)
- #139791 (drop global where-bounds before merging candidates)
- #139798 (normalize: prefer `ParamEnv` over `AliasBound` candidates)
- #139822 (Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix)
- #139833 (Fix some HIR pretty-printing problems)
- #139836 (Basic tests of MPMC receiver cloning)
r? `@ghost`
`@rustbot` modify labels: rollup
cfi: do not transmute function pointers in formatting code Follow-up to #115954. Addresses #115199 point 2. Related to #128728. Discussion [on the LKML](https://lore.kernel.org/all/[email protected]/). cc `@maurer` `@rcvalle` `@RalfJung`
Reject test executables when not supported by target Currently, compiling tests for SOLID produces an ICE, because SOLID does not support executables. See rust-lang/rust#138047
Split `TypeFolder` and `FallibleTypeFolder` atwain
Right now there is a coherence problem with `TypeFolder` and `FallibleTypeFolder`. Namely, it's impossible to implement a `FallibleTypeFolder` that is generic over interner, b/c it has a *downstream* conflict with the blanket impl:
```
impl<I, F> FallibleTypeFolder<I> for F where F: TypeFolder<I> {}
```
Because downstream crates may implement `TypeFolder<SomeLocalInterner>` for the fallible type folder.
This PR removes the relationship between `FallibleTypeFolder` and `TypeFolder`; it leads to *modest* code duplication, but otherwise does not affect perf and really doesn't matter in general.
…henkov 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 rust-lang/rust#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: https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_target/src/spec/mod.rs#L2369 - We use the target default but this can be overriden by `-{C,Z} dwarf-version` https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L738 - The flag is validated https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1253-L1258 - When debuginfo is generated, we tell LLVM to use the requested value or the target default https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/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 rust-lang/rust#98350 by `@pcwalton` - Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang/rust#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](https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/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 (rust-lang/cc-rs#1395). --- Closes #103057
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.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please close and re-open this PR to trigger CI, then enable auto-merge.