Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: rust-lang/rust
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: master
Choose a base ref
...
head repository: Manishearth/rust
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: rollup-bzqapzs
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 11 commits
  • 101 files changed
  • 2 contributors

Commits on Nov 11, 2022

  1. Issue error when -C link-self-contained option is used on unsupport…

    …ed platforms
    
    Document supported targets for `-C link-self-contained`
    
    Move `LinkSelfContainedDefault::True` from wasm_base to wasm32_wasi
    StackDoubleFlow committed Nov 11, 2022

    Verified

    This commit was signed with the committer’s verified signature.
    StackDoubleFlow StackDoubleFlow
    Copy the full SHA
    f6d7f08 View commit details
  2. Rollup merge of #102049 - fee1-dead-contrib:derive_const, r=oli-obk

    Add the `#[derive_const]` attribute
    
    Closes #102371. This is a minimal patchset for the attribute to work. There are no restrictions on what traits this attribute applies to.
    
    r? ````@oli-obk````
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    2c5a883 View commit details
  3. Rollup merge of #102701 - flba-eb:add_qnx_nostd_support, r=cjgillot

    Add tier 3 no_std AArch64/x86_64 support for the QNX Neutrino RTOS
    
    This change allows to compile `no_std` applications for the QNX Neutrino Real-time operating system for ARM 64 bit CPUs.
    Tested with QNX Neutrino 7.1.
    
    Partially discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Adding.20QNX.20as.20target).
    
    ---
    
    > ## Tier 3 target policy
    >
    > At this tier, the Rust project provides no official support for a target, so we
    place minimal requirements on the introduction of targets.
    >
    >A proposed new tier 3 target must be reviewed and approved by a member of the
    compiler team based on these requirements. The reviewer may choose to gauge
    broader compiler team consensus via a [Major Change Proposal (MCP)][MCP].
    >
    >A proposed target or target-specific patch that substantially changes code
    shared with other targets (not just target-specific code) must be reviewed and
    approved by the appropriate team for that shared code before acceptance.
    >
    >- 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.)
    
    See also nto-qnx.md; designated developers are:
    
    - Florian Bartels, `[email protected]`, https://github.com/flba-eb
    - Tristan Roach, `[email protected]`, https://github.com/gh-tr
    
    > - 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.
    >  - 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.
    
    `aarch64-unknown-nto-qnx7.1.0` and `x86_64-pc-nto-qnx7.1.0` have been chosen as these
    strings are used in the official QNX Neutrino toolchain (for `C`/`C++`). It should also
    harmonize with the other Rust targets.
    
    The version (`7.1.0 `) is needed because libc needs to distinguish between different
    versions (`target_env` is set to `710` for QNX Neutrino 7.1): For example, functions are removed from 7.0
    to 7.1, sometimes the signature of functions is slightly changed or size/alignment of structs.
    I'm expecting the same for future versions.
    This works very well in e.g. `libc` (tested with 7.0 which I'm not going to support).
    
    > - 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.
    
    No issue as far as I can see.
    
    >  - Anything added to the Rust repository must be under the standard Rust
        license (`MIT OR Apache-2.0`).
    
    Ok
    
    >  - 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.
    
    No change for host tools. When cross-compiling for QNX Neutrino, the compiler/linker
    driver "qcc" is called. It should be possible (but not tested) to use other
    (OSS) compilers/linkers to produce working binaries.
    
    >  - 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.
    
    Only rustc is required for code generation (i.e. no additional libraries to
    generate code). Linking of executables requires the ordinary runtime libraries
    `crt` and `libc`.
    
    >  - "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.
    >- 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.
    
    I see no issues with any of the above.
    
    >- 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.
    
    `core` and `alloc` should be working (no change required). `std` implementation
    is ongoing and will be provided separately.
    
    >- 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.
    
    see nto-qnx.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.
    
    Ok
    
    >- 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.
    
    Ok
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    293b4f7 View commit details
  4. Rollup merge of #103970 - oli-obk:unhide_unknown_spans, r=estebank

    Unhide unknown spans
    
    r? ``@estebank``
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    06244ed View commit details
  5. Rollup merge of #104105 - davidtwco:split-dwarf-lto, r=michaelwoerister

    llvm: dwo only emitted when object code emitted
    
    Fixes #103932.
    
    `CompiledModule` should not think a DWARF object was emitted when a bitcode-only compilation has happened, this can confuse archive file creation (which expects to create an archive containing non-existent dwo files).
    
    r? ````@michaelwoerister````
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    a36e1ac View commit details
  6. Rollup merge of #104110 - krasimirgg:msan-16, r=nagisa

    prevent uninitialized access in black_box for zero-sized-types
    
    Don't read the pointer location in black_box for zero sized types, just emit a memory clobber instead. Addresses  #103304 when rust is build against LLVM at HEAD.
    
    Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/.28with.20llvm.20at.20HEAD.29.3A.20msan.20error.20in.20core.3A.3Ahint.3A.3Ablack_box
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    cc1fddc View commit details
  7. Rollup merge of #104117 - crlf0710:update_feature_gate, r=jackh726

    Mark `trait_upcasting` feature no longer incomplete.
    
    This marks the `trait_upcasting` feature no longer incomplete since #101336 has been settled for a little while.
    
    r? ````@jackh726````
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    dd4b803 View commit details
  8. Rollup merge of #104137 - StackDoubleFlow:err-lsc-unsupported, r=petr…

    …ochenkov
    
    Issue error when -C link-self-contained option is used on unsupported platforms
    
    The documentation was also updated to reflect this.
    
    I'm assuming the supported platforms are the same as initially written in [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler-17).
    
    Fixes #103576
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    64df701 View commit details
  9. Rollup merge of #104144 - TaKO8Ki:suggest-removing-unnecessary-dot, r…

    …=fee1-dead
    
    Suggest removing unnecessary `.` to use a floating point literal
    
    Fixes a part of #101883
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    e944a06 View commit details
  10. Rollup merge of #104206 - compiler-errors:ocx-more-2, r=lcnr

    Remove `save_and_restore_in_snapshot_flag`, use `ObligationCtxt` more
    
    r? ``@lcnr``
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    c77bd67 View commit details
  11. Rollup merge of #104302 - weihanglo:update-cargo, r=weihanglo

    Update cargo
    
    9 commits in 9286a1beba5b28b115bad67de2ae91fb1c61eb0b..a3dfea71ca0c888a88111086898aa833c291d497 2022-11-04 06:41:49 +0000 to 2022-11-11 03:50:47 +0000
    - fix: return non UTF-8 error message (rust-lang/cargo#11321)
    - Extract `two_kinds_of_msg_format_err` message to de-duplicate it (rust-lang/cargo#11358)
    - Propagate change of artifact bin dep to its parent fingerprint (rust-lang/cargo#11353)
    - Fix not a hyperlink warnings (rust-lang/cargo#11357)
    - Fix wait-for-publish with sparse registry (rust-lang/cargo#11356)
    - Add `rm` alias to configuration docs (rust-lang/cargo#11351)
    - Add `registries.crates-io.protocol` docs (rust-lang/cargo#11350)
    - test(features2): test to prevent regressing of optional host deps of dep (rust-lang/cargo#11342)
    - Bump to 0.68.0, update changelog (rust-lang/cargo#11340)
    
    r? ```@ghost```
    Manishearth authored Nov 11, 2022

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    e93dae2 View commit details
Loading