)]}'
{
  "commit": "2ad5ffeccae41d93decf323fb6cfdee5225fdc19",
  "tree": "839d8182719b4192bb3e4a34c2cf27de3e5a6ef4",
  "parents": [
    "d638e47e11faa59411151071eb7b9cb5e0cc4d74",
    "72e20774b661e0751d598fbeb813f4b0d7ead58f"
  ],
  "author": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Wed Apr 16 22:14:01 2025 +0000"
  },
  "committer": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Wed Apr 16 22:14:01 2025 +0000"
  },
  "message": "Auto merge of #138011 - tnewsome-lynx:lynxos_178-nostd, r\u003ddavidtwco\n\nAdd minimal x86_64-lynx-lynxos178 support.\n\nAdd minimal x86_64-lynx-lynxos178 support. It\u0027s possible to build no_std\nprograms with this compiler.\n\n## Tier 3 Target Policy\n\n\u003e A tier 3 target must have a designated developer or developers (the \"target\nmaintainers\") on record to be CCed when issues arise regarding the target. (The\nmechanism to track and CC such developers may evolve over time.)\n\nTim Newsome (`@tnewsome-lynx)` will be the designated developer for\nx86_64-lynx-lynxos178 support.\n\n\u003e Targets must use naming consistent with any existing targets; for instance, a\ntarget for the same CPU or OS as an existing Rust target should use the same\nname for that CPU or OS. Targets should normally use the same names and naming\nconventions as used elsewhere in the broader ecosystem beyond Rust (such as in\nother toolchains), unless they have a very good reason to diverge. Changing the\nname of a target can be highly disruptive, especially once the target reaches a\nhigher tier, so getting the name right is important even for a tier 3 target.\n\nI believe the target is named appropriately.\n\n\u003e Target names should not introduce undue confusion or ambiguity unless\nabsolutely necessary to maintain ecosystem compatibility. For example, if the\nname of the target makes people extremely likely to form incorrect beliefs about\nwhat it targets, the name should be changed or augmented to disambiguate it.\n\nThe target name is not confusing.\n\n\u003e If possible, use only letters, numbers, dashes and underscores for the name.\nPeriods (.) are known to cause issues in Cargo.\n\nDone.\n\n\u003e Tier 3 targets may have unusual requirements to build or use, but must not\ncreate legal issues or impose onerous legal terms for the Rust project or for\nRust developers or users.\n\u003e The target must not introduce license incompatibilities.\n\u003e Anything added to the Rust repository must be under the standard Rust license\n(MIT OR Apache-2.0).\n\nAll this new code is licensed under the Apache-2.0 license.\n\n\u003e The target must not cause the Rust tools or libraries built for any other host\n(even when supporting cross-compilation to the target) to depend on any new\ndependency less permissive than the Rust licensing policy. This applies whether\nthe dependency is a Rust crate that would require adding new license exceptions\n(as specified by the tidy tool in the rust-lang/rust repository), or whether the\ndependency is a native library or binary. In other words, the introduction of\nthe target must not cause a user installing or running a version of Rust or the\nRust tools to be subject to any new license requirements.\n\nDone.\n\n\u003e Compiling, linking, and emitting functional binaries, libraries, or other code\nfor the target (whether hosted on the target itself or cross-compiling from\nanother target) must not depend on proprietary (non-FOSS) libraries. Host tools\nbuilt for the target itself may depend on the ordinary runtime libraries\nsupplied by the platform and commonly used by other applications built for the\ntarget, but those libraries must not be required for code generation for the\ntarget; cross-compilation to the target must not require such libraries at all.\nFor instance, rustc built for the target may depend on a common proprietary C\nruntime library or console output library, but must not depend on a proprietary\ncode generation library or code optimization library. Rust\u0027s license permits\nsuch combinations, but the Rust project has no interest in maintaining such\ncombinations within the scope of Rust itself, even at tier 3.\n\nI think we\u0027re in the clear here. We do link against some static libraries that\nare proprietary (like libm and libc), but those are not used to generate code.\nE.g. the VxWorks target requires `wr-c++` to be installed, which is not\npublically available.\n\n\u003e \"onerous\" here is an intentionally subjective term. At a minimum, \"onerous\"\nlegal/licensing terms include but are not limited to: non-disclosure\nrequirements, non-compete requirements, contributor license agreements (CLAs) or\nequivalent, \"non-commercial\"/\"research-only\"/etc terms, requirements conditional\non the employer or employment of any particular Rust developers, revocable\nterms, any requirements that create liability for the Rust project or its\ndevelopers or users, or any requirements that adversely affect the livelihood or\nprospects of the Rust project or its developers or users.\n\nOur intention is to allow anyone with access to LynxOS CDK to use Rust for it.\n\n\u003e Neither this policy nor any decisions made regarding targets shall create any\nbinding agreement or estoppel by any party. If any member of an approving Rust\nteam serves as one of the maintainers of a target, or has any legal or\nemployment requirement (explicit or implicit) that might affect their decisions\nregarding a target, they must recuse themselves from any approval decisions\nregarding the target\u0027s tier status, though they may otherwise participate in\ndiscussions.\n\u003e This requirement does not prevent part or all of this policy from being cited\nin an explicit contract or work agreement (e.g. to implement or maintain support\nfor a target). This requirement exists to ensure that a developer or team\nresponsible for reviewing and approving a target does not face any legal threats\nor obligations that would prevent them from freely exercising their judgment in\nsuch approval, even if such judgment involves subjective matters or goes beyond\nthe letter of these requirements.\n\nNo problem.\n\n\u003e Tier 3 targets should attempt to implement as much of the standard libraries\nas possible and appropriate (core for most targets, alloc for targets that can\nsupport dynamic memory allocation, std for targets with an operating system or\nequivalent layer of system-provided functionality), but may leave some code\nunimplemented (either unavailable or stubbed out as appropriate), whether\nbecause the target makes it impossible to implement or challenging to implement.\nThe authors of pull requests are not obligated to avoid calling any portions of\nthe standard library on the basis of a tier 3 target not implementing those\nportions.\n\nWith this first PR, only core is supported. I am working on support for the std\nlibrary and intend to submit that once all the tests are passing.\n\n\u003e The target must provide documentation for the Rust community explaining how to\nbuild for the target, using cross-compilation if possible. If the target\nsupports running binaries, or running tests (even if they do not pass), the\ndocumentation must explain how to run such binaries or tests for the target,\nusing emulation if possible or dedicated hardware if necessary.\n\nThis is documented in `src/doc/rustc/src/platform-support/lynxos178.md`.\n\n\u003e Tier 3 targets must not impose burden on the authors of pull requests, or\nother developers in the community, to maintain the target. In particular, do not\npost comments (automated or manual) on a PR that derail or suggest a block on\nthe PR based on a tier 3 target. Do not send automated messages or notifications\n(via any medium, including via `@)` to a PR author or others involved with a PR\nregarding a tier 3 target, unless they have opted into such messages.\n\u003e Backlinks such as those generated by the issue/PR tracker when linking to an\nissue or PR are not considered a violation of this policy, within reason.\nHowever, such messages (even on a separate repository) must not generate\nnotifications to anyone involved with a PR who has not requested such\nnotifications.\n\nUnderstood.\n\n\u003e Patches adding or updating tier 3 targets must not break any existing tier 2\nor tier 1 target, and must not knowingly break another tier 3 target without\napproval of either the compiler team or the maintainers of the other tier 3\ntarget.\n\u003e In particular, this may come up when working on closely related targets, such\nas variations of the same architecture with different features. Avoid\nintroducing unconditional uses of features that another variation of the target\nmay not have; use conditional compilation or runtime detection, as appropriate,\nto let each target run code supported by that target.\n\nAs far as I know this change does not affect any other targets.\n\n\u003e Tier 3 targets must be able to produce assembly using at least one of rustc\u0027s\nsupported backends from any host target. (Having support in a fork of the\nbackend is not sufficient, it must be upstream.)\n\nMany targets produce assembly for x86_64 so that also works for LynxOS-178.\n",
  "tree_diff": []
}