| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Update table of contents in about-this-guide.md
|
|
1. added two new parts: Bootstrapping and Supporting Infrastructure;
2. touched up names of pre-existing parts, to match actual names in sidebar;
3. syntactic nits (start description of Analysis with a capital letter); and
4. make numbered list use only 1.
Co-authored-by: Tshepang Mbambo <tshepang@gmail.com>
|
|
Fix breakage when running compiletest with `--test-args=--edition=2015`
Compiletest has an `--edition` flag to change the default edition tests are run with. Unfortunately no test suite successfully executes when that flag is passed. If the edition is set to something greater than 2015 the breakage is expected, since the test suite currently supports only edition 2015 (Ferrous Systems will open an MCP about fixing that soonish). Surprisingly, the test suite is also broken if `--edition=2015` is passed to compiletest. This PR focuses on fixing the latter.
This PR fixes the two categories of failures happening when `--edition=2015` is passed:
* Some edition-specific tests set their edition through `//@ compile-flags` instead of `//@ edition`. Compiletest doesn't parse the compile flags, so it would see no `//@ edition` and add another `--edition` flag, leading to a rustc error.
* Compiletest would add the edition after `//@ compile-flags`, while some tests depend on flags passed to `//@ compile-flags` being the last flags in the rustc invocation.
Note that for the first category, I opted to manually go and replace all `//@ compile-flags` setting an edition with an explicit `//@ edition`. We could've changed compiletest to instead check whether an edition was set in `//@ compile-flags`, but I thought it was better to enforce a consistent way to set the edition in tests.
I also added the edition to the stamp, so that changing `--edition` results in tests being re-executed.
r? `@jieyouxu`
|
|
|
|
Introduce a `//@ needs-crate-type` compiletest directive
The `//@ needs-crate-type: $crate_types...` directive takes a comma-separated list of crate types that the target platform must support in order for the test to be run. This allows the test writer to semantically convey that the ignore condition is based on target crate type needs, instead of using a general purpose `//@ ignore-$target` directive (often without comment).
Fixes #132309.
### Example
```rs
//@ needs-crate-type: dylib (ignored on e.g. wasm32-unknown-unknown)
//@ compile-flags: --crate-type=dylib
fn foo() {}
```
### Review advice
- Best reviewed commit-by-commit.
- The impl is not very clean, I briefly attempted to clean up the directive handling but found that more invasive changes are needed, so I'd like to not block on the cleanup for now.
try-job: test-various
try-job: armhf-gnu
|
|
and its use cases in more detail
|
|
It's possible to build no_std programs with this compiler.
> 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/lynxos_178.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.
|
|
|
|
fix title of offset_of_enum feature
tracking issue #120141
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #139494 (Restrict some queries by def-kind more)
- #139496 (Revert r-a changes of rust-lang/rust#139455)
- #139506 (add missing word in doc comment (part 2))
- #139515 (Improve presentation of closure signature mismatch from `Fn` trait goal)
- #139520 (compiletest maintenance: sort deps and drop dep on `anyhow`)
- #139523 (Rustc dev guide subtree update)
- #139526 (Fix deprecation note for std::intrinsics)
- #139528 (compiletest: Remove the `--logfile` flag)
- #139541 (Instantiate higher-ranked transmute goal w/ placeholders before emitting sub-obligations)
- #139547 (Update library tracking issue template to set S-tracking-unimplemented)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Rustc dev guide subtree update
r? `@jieyouxu`
|
|
Update books
## rust-lang/reference
12 commits in e95ebdfee02514d93f79ec92ae310a804e87f01f..46435cd4eba11b66acaa42c01da5c80ad88aee4b
2025-04-07 14:21:21 UTC to 2025-03-25 20:13:17 UTC
- Update book.toml fix the authors field (rust-lang/reference#1780)
- Update precedence table for borrow operators (rust-lang/reference#1776)
- Add the ability for rules to be specified in link definitions (rust-lang/reference#1775)
- Rework trait parameter patterns (rust-lang/reference#1771)
- Fix header rules (rust-lang/reference#1770)
- Add test wrappers (rust-lang/reference#1774)
- Update tools to Rust 2024 (rust-lang/reference#1773)
- Define byte (rust-lang/reference#1772)
- Fix CSS for new footnote style (rust-lang/reference#1777)
- do not reference LLVM in our definition of UB (rust-lang/reference#1750)
- Tweak reference for precise capturing in traits (rust-lang/reference#1769)
- Add edition admonitions (rust-lang/reference#1764)
## rust-lang/rust-by-example
2 commits in 6f69823c28ae8d929d6c815181c73d3e99ef16d3..0d7964d5b22cf920237ef1282d869564b4883b88
2025-04-07 11:19:31 UTC to 2025-03-29 02:25:52 UTC
- Rename count to index for clarity (rust-lang/rust-by-example#1920)
- Fixing grammar in panic section (rust-lang/rust-by-example#1916)
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
targets
also mention the MSVC alignment issue in platform-support.md
|
|
|
|
|
|
Remove support for `extern "rust-intrinsic"` blocks
Part of rust-lang/rust#132735
Looked manageable and there didn't appear to have been progress in the last two weeks,
so decided to give it a try.
|
|
|
|
|
|
|
|
|
|
- src\doc\nomicon\src\ffi.md should also have its ABI list updated
|
|
|
|
unstable book: document tait
Documents the type alias impl trait feature.
Rendered:
because you are deeply involved in this I'll r you but feel free to reroll
r? `@oli-obk`
|
|
Noratrieb:Now_I_am_become_death,_the_destroyer_of_i686-pc-windows-gnu, r=workingjubilee
Demote i686-pc-windows-gnu to Tier 2
In accordance with [RFC 3771](https://github.com/rust-lang/rfcs/pull/3771). FCP has been completed.
tracking issue #138422
I also added a stub doc page for the target and renamed the windows-gnullvm page for consistency.
|
|
See https://rust-lang.github.io/mdBook/format/configuration/general.html#general-metadata
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #139080 (Experimental feature gate for `super let`)
- #139145 (slice: Remove some uses of unsafe in first/last chunk methods)
- #139149 (unstable book: document import_trait_associated_functions)
- #139273 (Apply requested API changes to `cell_update`)
- #139282 (rustdoc: make settings checkboxes always square)
- #139283 (Rustc dev guide subtree update)
- #139294 (Fix the `f16`/`f128` feature gates on integer literals)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Rustc dev guide subtree update
r? ``@jieyouxu`` ``@Kobzol``
|
|
unstable book: document import_trait_associated_functions
Documents https://github.com/rust-lang/rust/issues/134691 which was implemented in https://github.com/rust-lang/rust/pull/134754
|
|
|
|
In accordance with RFC 3771.
I also added a stub doc page for the target and renamed the
windows-gnullvm page for consistency.
|
|
|
|
|
|
Add unstable `--print=crate-root-lint-levels`
This PR implements `--print=crate-root-lint-levels` from MCP 833 https://github.com/rust-lang/compiler-team/issues/833.
Tracking issue: https://github.com/rust-lang/rust/issues/139180
Best reviewed commit by commit.
|
|
Update mdbook to 0.4.48
This brings in several updates. Two significant ones are to halve the search index size, and the other introduces major changes to footnote rendering.
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0448
|
|
fix dead link netbsd.md
src/doc/rustc/src/platform-support/netbsd.md
https://github.com/NetBSD/pkgsrc-wip/blob/master/rust/Makefile - https://github.com/NetBSD/pkgsrc-wip/blob/master/Makefile
|
|
|
|
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
|
|
This brings in several updates. Two significant ones are to halve the
search index size, and the other introduces major changes to footnote
rendering.
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0448
|
|
Update netbsd.md
Update netbsd.md
|
|
Introduce `-Zembed-metadata` to allow omitting full metadata from rlibs and dylibs
This is a continuation of https://github.com/rust-lang/rust/pull/120855 (I was mentored by `@bjorn3` to move it forward). Most of the original code was written by bjorn3, I tried to clean it up a bit and add some documentation and tests.
This PR introduces a new unstable compiler flag called `-Zembed-metadata=[no|yes]`, with the default being `yes` (see https://github.com/rust-lang/rust/issues/57076 for context). When set to `no`, rustc will only store a small metadata stub inside rlibs/dylibs instead of the full metadata, to keep their size smaller. It should be used in combination with `--emit=metadata`, so that the users of such a compiled library can still read the metadata from the corresponding `.rmeta` file. [This comment](https://github.com/rust-lang/rust/pull/120855#issuecomment-1937018169) shows an example of binary/artifact size wins that can be achieved using this approach.
Contrary to https://github.com/rust-lang/rust/pull/120855, this PR only introduces the new flag, along with a couple of run-make tests and documentation, but does not yet use it in bootstrap to actually compile rustc. I plan to do that as a follow-up step (along with integration in Cargo, which should ideally just always pass this flag to reduce the size of target directories).
Fixes https://github.com/rust-lang/rust/issues/23366
Closes https://github.com/rust-lang/rust/issues/29511
Fixes https://github.com/rust-lang/rust/issues/57076
Another attempt of https://github.com/rust-lang/rust/pull/93945 and https://github.com/rust-lang/rust/pull/120855.
r? `@petrochenkov`
|
