- 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.)
For all Rust targets on FreeBSD, it's rust@FreeBSD.org.
- 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.
Done.
- 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.
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.
Done.
- The target must not introduce license incompatibilities.
Done.
- Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Fine with me.
- 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.
- If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. 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.
Done.
- Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
Done.
- "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.
Fine with me.
- 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.
Ok.
- 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.
Ok.
- 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.
std is implemented.
- 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 tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.
Hm, building is possible the same way as other Rust on FreeBSD targets.
- 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.
Ok.
- 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.
Ok.
- 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.
Rollup merge of #87359 - jyn514:bless-rustup, r=estebank
Remove detection of rustup and cargo in 'missing extern crate' diagnostics
Previously, this would change the test output when RUSTUP_HOME was set:
```
---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ----
diff of stderr:
1 error[E0463]: can't find crate for `core`
2 |
3 = note: the `thumbv7em-none-eabihf` target may not be installed
+ = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf`
4
5 error: aborting due to previous error
6
```
Originally, I fixed it by explicitly unsetting RUSTUP_HOME in
compiletest. Then I realized that almost no one has RUSTUP_HOME set,
since rustup doesn't set it itself. It does set RUST_RECURSION_COUNT
whenever it launches a proxy, though - use that instead.
r? ```@estebank``` cc ```@petrochenkov``` ```@kinnison```
Rollup merge of #87348 - SkiFire13:fix-87261, r=oli-obk
Fix span when suggesting to add an associated type bound
Fixes #87261
Note that this fix is not perfect, it ~~will still give incorrect~~ won't give suggestions in some situations:
- If the associated type is defined on a supertrait of those contained in the opaque type, it will fallback to the previous behaviour, e.g. if `AssocTy` is defined on the trait `Foo`, `Bar` has `Foo` as supertrait and the opaque type is a `impl Bar + Baz`.
- If the the associated type is defined on a generic trait and the opaque type includes two versions of that generic trait, e.g. the opaque type is `impl Foo<A> + Foo<B>`
Auto merge of #87296 - Aaron1011:inert-warn, r=petrochenkov
Warn on inert attributes used on bang macro invocation
These attributes are currently discarded.
This may change in the future (see #63221), but for now,
placing inert attributes on a macro invocation does nothing,
so we should warn users about it.
Technically, it's possible for there to be attribute macro
on the same macro invocation (or at a higher scope), which
inspects the inert attribute. For example:
Auto merge of #86461 - crlf0710:rich_vtable, r=nikomatsakis
Refactor vtable format for upcoming trait_upcasting feature.
This modifies vtable format:
1. reordering occurrence order of methods coming from different traits
2. include `VPtr`s for supertraits where this vtable cannot be directly reused during trait upcasting.
Also, during codegen, the vtables corresponding to these newly included `VPtr` will be requested and generated.
For the cases where this vtable can directly used, now the super trait vtable has exactly the same content to some prefix of this one.
r? `@bjorn3`
cc `@RalfJung`
cc `@rust-lang/wg-traits`
Auto merge of #87338 - SparrowLii:MaybeTrait, r=wesleywiser
Simplify the collecting of `? Trait` bounds in where clause
This PR fixes the FIXME about using less rightward drift and only one error reporting when collecting of `?Trait` bounds in where clause.
Checking whether the path length of `bound_ty` is 1 can be replaced by whether `unresolved_segments` in the partial_res is 0.
Checking whether the `param.kind` is `Type{...}` can also be omitted. One Fx hash calculation will be done for Const or Lifetime param, but the impact on efficiency should be small IMO
Joshua Nelson [Thu, 22 Jul 2021 02:04:05 +0000 (02:04 +0000)]
Remove detection of rustup and cargo in 'missing extern crate' diagnostics
Previously, this would change the test output when RUSTUP_HOME was set:
```
---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ----
diff of stderr:
1 error[E0463]: can't find crate for `core`
2 |
3 = note: the `thumbv7em-none-eabihf` target may not be installed
+ = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf`
4
5 error: aborting due to previous error
6
```
Originally, I fixed it by explicitly unsetting RUSTUP_HOME in
compiletest. Then I realized that almost no one has RUSTUP_HOME set,
since rustup doesn't set it itself; although it does set RUST_RECURSION_COUNT
whenever it launches a proxy. Then it was pointed out that this runtime
check doesn't really make sense and it's fine to make it unconditional.
Auto merge of #87413 - JohnTitor:rollup-dht22jk, r=JohnTitor
Rollup of 14 pull requests
Successful merges:
- #86410 (VecMap::get_value_matching should return just one element)
- #86790 (Document iteration order of `retain` functions)
- #87171 (Remove Option from BufWriter)
- #87175 (Stabilize `into_parts()` and `into_error()`)
- #87185 (Fix panics on Windows when the build was cancelled)
- #87191 (Package LLVM libs for the target rather than the build host)
- #87255 (better support for running libcore tests with Miri)
- #87266 (Add testcase for 87076)
- #87283 (Add `--codegen-backends=foo,bar` configure flag)
- #87322 (fix: clarify suggestion that `&T` must refer to `T: Sync` for `&T: Send`)
- #87358 (Fix `--dry-run` when download-ci-llvm is set)
- #87380 (Don't default to `submodules = true` unless the rust repo has a .git directory)
- #87398 (Add test for fonts used for module items)
- #87412 (Add missing article)
Rollup merge of #87358 - jyn514:dry-run, r=Mark-Simulacrum
Fix `--dry-run` when download-ci-llvm is set
Previously it would error out:
```
$ x check --dry-run
thread 'main' panicked at 'std::fs::read_to_string(ci_llvm.join("link-type.txt")) failed with No such file or directory (os error 2) ("CI llvm missing: /home/joshua/rustc3/build/tmp-dry-run/x86_64-unknown-linux-gnu/ci-llvm")', src/bootstrap/config.rs:795:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:10
```
Rollup merge of #87322 - chazkiker2:fix/suggestion-ref-sync-send, r=estebank
fix: clarify suggestion that `&T` must refer to `T: Sync` for `&T: Send`
### Description
- [x] fix #86507
- [x] add UI test for relevant code from issue
- [x] change `rustc_trait_selection/src/traits/error_reporting/suggestions.rs` to include a more clear suggestion when `&T` fails to satisfy `Send` bounds due to the fact that `T` fails to implement `Sync`
- [x] update UI test in Clippy: `src/tools/tests/ui/future_not_send.stderr`
Rollup merge of #87255 - RalfJung:miri-test-libcore, r=Mark-Simulacrum
better support for running libcore tests with Miri
See https://github.com/rust-lang/miri-test-libstd/issues/4 for a description of the problem that this fixes.
Thanks to `@hyd-dev` for suggesting this patch!
`dist.rs` uses, in the `rust-dev` stage, `llvm-config --libfiles` to get a list of the LLVM library files built but of course only for the build host. If the target differs we want to package lib files from the target's build tree instead. This is done by splitting/rejoining the paths on their build directories.
At the moment `tree` on the LLVM build directories seems to give almost identical output, but of course this might not be the case in the future. If a file is missing in the target's build tree then this stage will error in the `builder.install()` call. If the target build tree has an extra file then it silently won't be copied and we'll get a linker error when building using this artifact (via `download-ci-llvm = "if-available"`), though we would have received a linker error anyway without this change.
There was also a typo in the example config around this option.
Rollup merge of #87175 - inquisitivecrystal:inner-error, r=kennytm
Stabilize `into_parts()` and `into_error()`
This stabilizes `IntoInnerError`'s `into_parts()` and `into_error()` methods, currently gated behind the `io_into_inner_error_parts` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/79704#issuecomment-880652967)
Rollup merge of #86790 - janikrabe:retain-iter-order-doc, r=m-ou-se
Document iteration order of `retain` functions
For `HashSet` and `HashMap`, this simply copies the comment from
`BinaryHeap::retain`.
For `BTreeSet` and `BTreeMap`, this adds an additional guarantee that
wasn't previously documented. I think that because these data structures
are inherently ordered and other functions guarantee ordered iteration,
it makes sense to provide this guarantee for `retain` as well.
Auto merge of #87400 - JohnTitor:rollup-zbwyuxi, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #87034 (DOC: fix hypothetical Rust code in `step_by()` docstring)
- #87298 (memorialize Anna Harren in the bastion of the turbofish)
- #87332 (Don't hide fields of enum struct variants)
- #87362 (Make `x.py d` an alias for `x.py doc`)
- #87372 (Move calls to test_main into one function)
- #87373 (Extend HIR WF checking to fields)
- #87376 (Change rustdoc logo to use the full container size)
- #87383 (Add regression tests for the impl_trait_in_bindings ICEs)
Rollup merge of #87376 - Thomasdezeeuw:rustdoc-large-logo, r=GuillaumeGomez
Change rustdoc logo to use the full container size
We have a logo in svg that scales nicely to large sizes, but by default
is only 5px large, i.e. very small. With the change the logo expands to
the full size. By only setting the height to 100% we ensure that the
width-height ratio isn't changed.
Rollup merge of #87362 - inquisitivecrystal:bootstrap-doc, r=jyn514
Make `x.py d` an alias for `x.py doc`
In rust-lang/cargo#9680, `d` was added to Cargo as an alias for `doc`. This PR adds the same alias to `x.py`. The same considerations of convenience that applied to Cargo also apply to `x.py`, and in any case, the two should be kept symmetrical.
Rollup merge of #87332 - camelid:dont-hide-fields, r=GuillaumeGomez
Don't hide fields of enum struct variants
* The toggle adds visual clutter
* It's easy to miss that there are fields
* Tuple variant fields are always shown, so it is inconsistent to hide
struct variant fields
* It's annoying to have to click the toggle every time
Rollup merge of #87034 - mgeier:doc-step_by, r=JohnTitor
DOC: fix hypothetical Rust code in `step_by()` docstring
I don't know how important that is, but if I'm not mistaken, the hypothetical code in the docstring of `step_by()` (see https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.step_by) isn't correct.
I guess writing `next()` instead of `self.next()` isn't a biggie, but this would also imply that `advance_n_and_return_first()` is a method, which AFAICT it isn't.
I've also done some re-formatting in a separate commit and a parameter renaming in yet another commit.
Feel free to take or leave any combination of those commits.
Auto merge of #87287 - oli-obk:fixup_fixup_fixup_opaque_types, r=spastorino
Make mir borrowck's use of opaque types independent of the typeck query's result
fixes #87218
fixes #86465
we used to use the typeck results only to generate an obligation for the mir borrowck type to be equal to the typeck result.
When i removed the `fixup_opaque_types` function in #87200, I exposed a bug that showed that mir borrowck can't doesn't get enough information from typeck in order to build the correct lifetime mapping from opaque type usage to the actual concrete type. We therefor now fully compute the information within mir borrowck (we already did that, but we only used it to verify the typeck result) and stop using the typeck information.
We will likely be able to remove most opaque type information from the borrowck results in the future and just have all current callers use the mir borrowck result instead.
Noah Lev [Mon, 17 May 2021 23:49:38 +0000 (16:49 -0700)]
Don't hide fields of enum struct variants
* The toggle adds visual clutter
* It's easy to miss that there are fields
* Tuple variant fields are always shown, so it is inconsistent to hide
struct variant fields
* It's annoying to have to click the toggle every time
Auto merge of #86212 - pnkfelix:mainline-targetted-revert-81473-warn-write-only-fields, r=simulacrum
Revert PR 81473 to resolve (on mainline) issues 81626 and 81658.
This is a nightly-targetted variant of PR #83171
The intent is to just address issue #81658 on all release channels, rather that keep repeatedly reverting PR #83171 on beta.
However, our intent is *also* to reland PR #83171 after we have addressed issue #81658 , most likely by coupling the re-landing of PR #83171 with an enhancement like PR #83004
Thomas de Zeeuw [Thu, 22 Jul 2021 15:57:06 +0000 (17:57 +0200)]
Change rustdoc logo to use the full container size
We have a logo in svg that scales nicely to large sizes, but by default
is only 5px large, i.e. very small. With the change the logo expands to
the full size. By only setting the height to 100% we ensure that the
width-height ratio isn't changed.
Auto merge of #87371 - ehuss:update-cargo, r=ehuss
Update cargo
2 commits in 4e143fd131e0c16cefd008456e974236ca54e62e..cebef2951ee69617852844894164b54ed478a7da
2021-07-20 21:55:45 +0000 to 2021-07-22 13:01:52 +0000
- Changes rustc argument from `--force-warns` to `--force-warn` (rust-lang/cargo#9714)
- Display registry name instead of registry URL when possible (rust-lang/cargo#9632)
Rollup merge of #87357 - lilyball:mailmap, r=jyn514
Update my name/email in .mailmap
I should have done this years ago.
My name is also scattered across many other rust-lang repos, but none of the other repos I've looked at have a `.mailmap`. Is there any particular reason for this, or any process for updating my name/email everywhere?
Rollup merge of #87343 - steffahn:fix_unsound_zip_optimization_only_regression_fix, r=cuviper
Regression fix to avoid further beta backports: Remove unsound TrustedRandomAccess implementations
Removes the implementations that depend on the user-definable trait `Copy`.
Only fix regressions to ensure merge in 1.55: Does not modify `vec::IntoIter`.
<hr>
This PR applies the beta-`1.53` backport #86222 (merged as part of #86225), a reduced version of #85874 that only fixes regressions, to `master` in order to avoid the need for further backports from `1.55` onwards. Beta-`1.54` backport already happened with #87136. In case that #85874 gets merged quickly (within a week), this PR would be unnecessary.
The `Escape` part is indeed no longer needed, because Tera does that for us. But the massaging of `-` to `_` is needed, for the (bizarre) reasons explained in the new comments.
I have tested that the default theme function works again for me. I have also verified that passing (in shell syntax)
Adds profiling instrumentation for the hashing of incremental compilation fingerprints per query.
This will eventually feed into the `measureme` and `rustc-perf` infrastructure for tracking if computing hashes changes over time.
TODOs:
* [x] Address the FIXME where we are including node interning in the hash timing.
* [ ] Update measureme/summarize to handle this new data: https://github.com/rust-lang/measureme/pull/166
* [ ] ~Update rustc-perf to handle the new data from measureme~ (will be done at a later time)
Auto merge of #87265 - Aaron1011:hir-wf-fn, r=estebank
Support HIR wf checking for function signatures
During function type-checking, we normalize any associated types in
the function signature (argument types + return type), and then
create WF obligations for each of the normalized types. The HIR wf code
does not currently support this case, so any errors that we get have
imprecise spans.
This commit extends `ObligationCauseCode::WellFormed` to support
recording a function parameter, allowing us to get the corresponding
HIR type if an error occurs. Function typechecking is modified to
pass this information during signature normalization and WF checking.
The resulting code is fairly verbose, due to the fact that we can
no longer normalize the entire signature with a single function call.
As part of the refactoring, we now perform HIR-based WF checking
for several other 'typed items' (statics, consts, and inherent impls).
As a result, WF and projection errors in a function signature now
have a precise span, which points directly at the responsible type.
If a function signature is constructed via a macro, this will allow
the error message to point at the code 'most responsible' for the error
(e.g. a user-supplied macro argument).
Auto merge of #87250 - robojumper:87199-sized-relaxation, r=nikomatsakis
Fix implicit Sized relaxation when attempting to relax other, unsupported trait
Fixes #87199.
Do note that this bug fix causes code like the `ref_arg::<[i32]>(&[5]);` line in the test case in combination with an affected function to no longer compile.
Joshua Nelson [Thu, 22 Jul 2021 02:01:42 +0000 (02:01 +0000)]
Fix `--dry-run` when download-ci-llvm is set
Previously it would error out:
```
$ x check --dry-run
thread 'main' panicked at 'std::fs::read_to_string(ci_llvm.join("link-type.txt")) failed with No such file or directory (os error 2) ("CI llvm missing: /home/joshua/rustc3/build/tmp-dry-run/x86_64-unknown-linux-gnu/ci-llvm")', src/bootstrap/config.rs:795:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:10
```
Auto merge of #86946 - Aaron1011:eval-proj-obligation, r=nikomatsakis
Improve caching during trait evaluation
Previously, we would 'forget' that we had `'static` regions in some
place during trait evaluation. This lead to us producing
`EvaluatedToOkModuloRegions` when we could have produced
`EvaluatedToOk`, causing us to perform unnecessary work.
This PR preserves `'static` regions when we canonicalize a predicate for
`evaluate_obligation`, and when we 'freshen' a predicate during trait
evaluation. Thie ensures that evaluating a predicate containing
`'static` regions can produce `EvaluatedToOk` (assuming that we
don't end up introducing any region dependencies during evaluation).
Building off of this improved caching, we use
`predicate_must_hold_considering_regions` during fulfillment of
projection predicates to see if we can skip performing additional work.
We already do this for trait predicates, but doing this for projection
predicates lead to mixed performance results without the above caching
improvements.
projects / rust.git / log