| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Also be more pedantic about spelling:
- LE? Is it "less than or equal to"? Say "little endian".
- We're Rust, not C, preserve the initial capital in "N64".
- "MUSL" doesn't stand for anything; Rich Felker spells it "musl".
|
|
In the process, be more pedantic about spelling:
- LE? Do you mean "limited edition"? It's "little endian".
- The name of the ABI is "N64" as in "Nintendo 64".
|
|
|
|
|
|
|
|
Fix misuses of a vs an
Fixes the misuse of "a" vs "an", according to English grammatical
expectations and using https://www.a-or-an.com/
|
|
Updates documentation for LLVM CFI support with recommended information
since the user can now rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
add notes about non-compliant FP behavior on 32bit x86 targets
Based on ton of prior discussion (see all the issues linked from https://github.com/rust-lang/unsafe-code-guidelines/issues/237), the consensus seems to be that these targets are simply cursed and we cannot implement the desired semantics for them. I hope I properly understood what exactly the extent of the curse is here, let's make sure people with more in-depth FP knowledge take a close look!
In particular for the tier 3 targets I have no clue which target is affected by which particular variant of the x86_32 FP curse. I assumed that `i686` meant SSE is used so the "floating point return value" is the only problem, while everything lower (`i586`, `i386`) meant x87 is used.
I opened https://github.com/rust-lang/rust/issues/114479 to concisely describe and track the issue.
Cc `@workingjubilee` `@thomcc` `@chorman0773` `@rust-lang/opsem`
Fixes https://github.com/rust-lang/rust/issues/73288
Fixes https://github.com/rust-lang/rust/issues/72327
|
|
|
|
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
|
|
Stdio support for UEFI
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
# Quirks
## Output Newline
- UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird.
- However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF.
## Input Newline
- `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
- Works fine with input redirection from file.
CC `@dvdhrm`
|
|
- Mention stdio support
- Update the example
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
Promote loongarch64-unknown-none* to Tier 2
MCP: https://github.com/rust-lang/compiler-team/issues/664
|
|
|
|
Document -Zlink-native-libraries
Originally added in #70095.
|
|
Originally added in #70095.
|
|
Amend style guide section for formatting where clauses in type aliases
This PR has two parts:
1. Amend wording about breaking before or after the `=`, which is a style guide bugfix to align it with current rustfmt behavior.
2. Explain how to format trailing (#89122) where clauses, which are preferred in both GATs (#90076) and type aliases (#114662).
r? `@joshtriplett`
|
|
|
|
Update books
## rust-embedded/book
1 commits in 99ad2847b865e96d8ae7b333d3ee96963557e621..eac173690b8cc99094e1d88bd49dd61127fbd285
2023-09-12 07:34:44 UTC to 2023-09-12 07:34:44 UTC
- USB connector-type correction (rust-embedded/book#360)
## rust-lang/nomicon
1 commits in e3f3af69dce71cd37a785bccb7e58449197d940c..ddfa4214487686e91b21aa29afb972c08a8f0d5b
2023-09-22 17:04:10 UTC to 2023-09-22 17:04:10 UTC
- Fill "Beneath `std`" (rust-lang/nomicon#413)
## rust-lang/reference
1 commits in ee7c676fd6e287459cb407337652412c990686c0..5262e1c3b43a2c489df8f6717683a44c7a2260fd
2023-09-18 18:28:31 UTC to 2023-09-18 18:28:31 UTC
- we reserve the right to reduce our amount of UB (rust-lang/reference#1397)
## rust-lang/rustc-dev-guide
8 commits in 08bb147d51e815b96e8db7ba4cf870f201c11ff8..a13b7c28ed705891c681ce5417b3d1cdb12cecd1
2023-09-25 05:14:41 UTC to 2023-09-11 21:29:18 UTC
- Clarify all the `{AP,RP}IT{,IT}` impl trait types (rust-lang/rustc-dev-guide#1798)
- Modify build instructions for optimized build (rust-lang/rustc-dev-guide#1795)
- Remove outdated references to coverage debug code (rust-lang/rustc-dev-guide#1797)
- Add deep dive document about early/late bound parameters interacting with turbofish (rust-lang/rustc-dev-guide#1794)
- explain the MIR const vs TY const situation (rust-lang/rustc-dev-guide#1793)
- fix type name (rust-lang/rustc-dev-guide#1792)
- Clarify that `run-coverage` only runs in some of the CI jobs (rust-lang/rustc-dev-guide#1791)
- Document the `coverage-map` and `run-coverage` test suites (rust-lang/rustc-dev-guide#1790)
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/664
|
|
|
|
|
|
Add Minimal Std implementation for UEFI
# Implemented modules:
1. alloc
2. os_str
3. env
4. math
# Related Links
Tracking Issue: https://github.com/rust-lang/rust/issues/100499
API Change Proposal: https://github.com/rust-lang/libs-team/issues/87
# Additional Information
This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR.
The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
|
|
Raise minimum supported Apple OS versions
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
- macOS: 10.12 Sierra
- iOS: 10
- tvOS: 10
- watchOS: 5 (Unchanged)
In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.
[Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
|
|
Drop the armv7-apple-ios target too because its no longer supported
with the hardware iOS 10 requires.
|
|
|
|
- Update Example
- Add thread_parking to sys::uefi
- Fix unsafe in unsafe errors
- Improve docs
- Improve os/exit
- Some asserts
- Switch back to atomics
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
- Some comment fixes.
- Make some functions unsafe.
- Make helpers module private.
- Rebase on master
- Update r-efi to v4.2.0
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
|
|
Implemented modules:
1. alloc
2. os_str
3. env
4. math
Tracking Issue: https://github.com/rust-lang/rust/issues/100499
API Change Proposal: https://github.com/rust-lang/libs-team/issues/87
This was originally part of https://github.com/rust-lang/rust/pull/100316. Since
that PR was becoming too unwieldy and cluttered, and with suggestion
from @dvdhrm, I have extracted a minimal std implementation to this PR.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
|
|
added support for GNU/Hurd
adding support for i686-unknown-hurd-gnu
|
|
|
|
style-guide: Document formatting of `as` casts (mostly like a binary operator)
`as` casts currently get formatted like a binary operator, except that
the second line can stack several `as` casts rather than breaking them
each onto their own line. Document this.
As far as I can tell (cc `@calebcartwright` for verification), this is not a 2024 edition change, it just documents current behavior.
|
|
style-guide: Add section on bugs, and resolving bugs
|
|
rustdoc-search: add support for type parameters
r? `@GuillaumeGomez`
## Preview
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/rustdoc/read-documentation/search.html
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=option%3Coption%3CT%3E%3E%20-%3E%20option%3CT%3E
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=option%3CT%3E,%20E%20-%3E%20result%3CT,%20E%3E
* https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=-%3E%20option%3CT%3E
## Description
When writing a type-driven search query in rustdoc, specifically one with more than one query element, non-existent types become generic parameters instead of auto-correcting (which is currently only done for single-element queries) or giving no result. You can also force a generic type parameter by writing `generic:T` (and can force it to not use a generic type parameter with something like `struct:T` or whatever, though if this happens it means the thing you're looking for doesn't exist and will give you no results).
There is no syntax provided for specifying type constraints for generic type parameters.
When you have a generic type parameter in a search query, it will only match up with generic type parameters in the actual function, not concrete types that match, not concrete types that implement a trait. It also strictly matches based on when they're the same or different, so `option<T>, option<U> -> option<U>` matches `Option::and`, but not `Option::or`. Similarly, `option<T>, option<T> -> option<T>` matches `Option::or`, but not `Option::and`.
## Motivation
This feature is motivated by the many "combinitor"-type functions found in generic libraries, such as Option, Future, Iterator, and Entry. These highly-generic functions have names that are almost completely arbitrary, and a type signature that tells you what it actually does.
This PR is a major step towards[^closure] being able to easily search for generic functions by their type signature instead of by name. Some examples of combinators that can be found using this PR (try them out in the preview):
* `option<option<T>> -> option<T>` returns Option::flatten
* `option<T> -> result<T>` returns Option::ok_or
* `option<result<T>> -> result<option<T>>` returns Option::transpose
* `entry<K, V>, FnOnce -> V` returns `Entry::or_insert_with` (and `or_insert_with_key`, since there's no way to specify the generics on FnOnce)
[^closure]:
For this feature to be as useful as it ought to be, you should be able to search for *trait-associated types* and *closures*. This PR does not implement either of these: they are **Future possibilities**.
Trait-associated types would allow queries like `option<T> -> iterator<item=T>` to return `Option::iter`. We should also allow `option<T> -> iterator<T>` to match the associated type version.
Closures would make a good way to query for things like `Option::map`. Closure support needs associated types to be represented in the search index, since `FnOnce() -> i32` desugars to `FnOnce<Output=i32, ()>`, so associated trait types should be implemented first. Also, we'd want to expose an easy way to query closures without specifying which of the three traits you want.
|
|
|
|
|
|
|
|
|
|
Rework `no_coverage` to `coverage(off)`
As discussed at the tail of https://github.com/rust-lang/rust/issues/84605 this replaces the `no_coverage` attribute with a `coverage` attribute that takes sub-parameters (currently `off` and `on`) to control the coverage instrumentation.
Allows future-proofing for things like `coverage(off, reason="Tested live", issue="#12345")` or similar.
|
|
Add `i686-pc-windows-gnullvm` triple
With various fixes that are already present in the code, a fully working i686 target can join other targets in `*-windows-gnullvm` family. Again this will be mostly useful for MSYS2 right now but I plan to open MCP for providing at least prebuilt std for `windows-gnullvm` as the next step which will expand usability of these targets.
Tier 3 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.)
I pledge to do my best maintaining it, MSYS2 is one of interested consumers. Previously added `gnullvm` triples proved there is not much maintenance required.
> 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.
This triple name is consistent with other targets and was discussed at [`t-compiler/LLVM+mingw-w64 Windows targets`](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets)
> 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.
I think the explanation in platform support doc is enough to make this aspect clear.
> 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.
It's using open source tools only.
> The target must not introduce license incompatibilities.
It's even more liberal than already existing `*-pc-windows-gnu`.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Understood.
> 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.
There are no new dependencies/features required.
> 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.
As previously said it's using open source tools only.
> "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.
There are no such terms present.
> 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.
I'm not the reviewer here.
> 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.
Again I'm not the reviewer here.
> 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.
It seems to work, at least for cross compilation.
> 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.
Building is described in platform support doc, running tests doesn't work right now (without hacks) because Rust's build system doesn't seem to support testing targets built from `.json`.
Docs will be updated once this lands in beta allowing master branch to build and run tests without `.json` files.
> 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.
Understood.
> 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.
I believe I didn't break any other 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.
I think there are no such problems in this PR.
|
|
|
|
own't -> won't
|
|
This didn't show up before, because of some unification bugs
that were fixed in 269cb579479ab950e85a2e4078810501c29d7465
|
