| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Follow up to #92746. Address #94510.
(cherry picked from commit 004f2ed219378235c24a5d6bdb34337200e6eeed)
|
|
(cherry picked from commit 5f7ca55df6a89e3caa3131a13490cc01956149e7)
|
|
|
|
|
|
Follow up to #92959. Address #94508.
|
|
|
|
[beta] backport fix for #94502
this issue was fixed as part of #93368, so i extracted the change from there
closes #94502
|
|
|
|
No branch protection metadata unless enabled
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.
This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.
Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
|
|
update auto trait lint for `PhantomData`
cc https://github.com/rust-lang/rust/issues/93367#issuecomment-1047898410
|
|
Fix ScalarInt to char conversion
to avoid panic for invalid Unicode scalar values
|
|
pre #89862 cleanup
changes used in #89862 which can be landed without the rest of this PR being finished.
r? `@estebank`
|
|
Stabilize `#[cfg(panic = "...")]`
[Stabilization PR](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr) for #77443
|
|
Rollup of 10 pull requests
Successful merges:
- #89892 (Suggest `impl Trait` return type when incorrectly using a generic return type)
- #91675 (Add MemTagSanitizer Support)
- #92806 (Add more information to `impl Trait` error)
- #93497 (Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped)
- #93814 (mips64-openwrt-linux-musl: correct soft-foat)
- #93847 (kmc-solid: Use the filesystem thread-safety wrapper)
- #93877 (asm: Allow the use of r8-r14 as clobbers on Thumb1)
- #93892 (Only mark projection as ambiguous if GAT substs are constrained)
- #93915 (Implement --check-cfg option (RFC 3013), take 2)
- #93953 (Add the `known-bug` test directive, use it, and do some cleanup)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
debuginfo: Support fat pointers to unsized tuples.
This PR makes fat pointer debuginfo generation handle the case of unsized tuples.
Fixes #93871
|
|
Add the `known-bug` test directive, use it, and do some cleanup
cc rust-lang/compiler-team#476
Now tests can be annotated with `known-bug`, which should indicate that the test *should* pass (or at least that the current output is a bug). Adding it relaxes the requirement to add error annotations to the test (though it is still allowed). In the future, this could be extended with further relaxations - with the goal to make adding these tests need minimal effort.
I've used this attribute for the GAT tests added in #93757.
Finally, I've also cleaned up `header.rs` in compiletest a bit, by extracting out a bit of common logic. I've also split out some of the directives into their own consts. This removes a lot of very similar functions from `Config` and makes `TestProps::load_from` read nicer.
I've split these into separate commits, so I in theory could split these into separate PRs if they're controversial, but I think they're pretty straightforward.
r? ``@Mark-Simulacrum``
|
|
Implement --check-cfg option (RFC 3013), take 2
This pull-request implement RFC 3013: Checking conditional compilation at compile time (https://github.com/rust-lang/rfcs/pull/3013) and is based on the previous attempt https://github.com/rust-lang/rust/pull/89346 by `@mwkmwkmwk` that was closed due to inactivity.
I have address all the review comments from the previous attempt and added some more tests.
cc https://github.com/rust-lang/rust/issues/82450
r? `@petrochenkov`
|
|
Only mark projection as ambiguous if GAT substs are constrained
A slightly more targeted version of #92917, where we only give up with ambiguity if we infer something about the GATs substs when probing for a projection candidate.
fixes #93874
also note (but like the previous PR, does not fix) #91762
r? `@jackh726`
cc `@nikomatsakis` who reviewed #92917
|
|
Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped
As a part of stabilizing the scrape examples extension in Cargo, I uncovered a bug where examples cannot be scraped from tests. See this test: https://github.com/rust-lang/cargo/pull/10343/files#diff-27aa4f012ebfebaaee61498d91d2370de460628405d136b05e77efe61e044679R2496
The issue is that when rustdoc is run on a test file, because `--test` is not passed as a rustc option, then functions annotated with `#[test]` are ignored by the compiler. So this PR changes rustdoc so when `--test` is passed in conjunction with a `--scrape-example-<suffix>` flag, then the `test` field of `rustc_interface::Config` is true.
r? `@camelid`
|
|
Add more information to `impl Trait` error
Fixes #92458
Let me know if I went overboard here, or if the suggestions could use some refinement.
r? `@estebank`
Feel free to reassign to someone else
|
|
Add MemTagSanitizer Support
Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html).
On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead.
On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR.
# Usage
`-Zsanitizer=memtag -C target-feature="+mte"`
# Comments/Caveats
* MemTagSanitizer is only supported on AArch64 targets with hardware support
* Requires `-C target-feature="+mte"`
* LLVM MemTagSanitizer currently only performs stack tagging.
# TODO
* Tests
* Example
|
|
Suggest `impl Trait` return type when incorrectly using a generic return type
Address #85991
When there is a type mismatch error and the return type is generic, and that generic parameter is not used in the function parameters, suggest replacing that generic with the `impl Trait` syntax.
r? `@estebank`
|
|
Address #85991
Suggest the `impl Trait` return type syntax if the user tried to return a generic parameter and we get a type mismatch
The suggestion is not emitted if the param appears in the function parameters, and only get the bounds that actually involve `T: ` directly
It also checks whether the generic param is contained in any where bound (where it isn't the self type), and if one is found (like `Option<T>: Send`), it is not suggested.
This also adds `TyS::contains`, which recursively vistits the type and looks if the other type is contained anywhere
|
|
Do not ICE when inlining a function with un-satisfiable bounds
Fixes #93008
This is kinda a hack... but it's the fix I thought had the least blast-radius.
We use `normalize_param_env_or_error` to verify that the predicates in the param env are self-consistent, since with RevealAll, a bad predicate like `<&'static () as Clone>` will be evaluated with an empty ParamEnv (since it references no generics), and we'll raise an error for it.
|
|
Add more info and suggestions to use of #[test] on invalid items
This pr changes the diagnostics for using `#[test]` on an item that can't be used as a test to explain that the attribute has no meaningful effect on non-functions and suggests the use of `#[cfg(test)]` for conditional compilation instead.
Example change:
```rs
#[test]
mod test {}
```
previously output
```
error: only functions may be used as tests
--> src/lib.rs:2:1
|
2 | mod test {}
| ^^^^^^^^^^^
```
now outputs
```
error: the `#[test]` attribute may only be used on a non-associated function
--> $DIR/test-on-not-fn.rs:3:1
|
LL | #[test]
| ^^^^^^^
LL | mod test {}
| ----------- expected a non-associated function, found a module
|
= note: the `#[test]` macro causes a a function to be run on a test and has no effect on non-functions
help: replace with conditional compilation to make the item only exist when tests are being run
|
LL | #[cfg(test)]
| ~~~~~~~~~~~~
```
|
|
Deny mixing bin crate type with lib crate types
The produced library would get a main shim too which conflicts with the
main shim of the executable linking the library.
```
$ cat > main1.rs <<EOF
fn main() {}
pub fn bar() {}
EOF
$ cat > main2.rs <<EOF
extern crate main1;
fn main() {
main1::bar();
}
EOF
$ rustc --crate-type bin --crate-type lib main1.rs
$ rustc -L. main2.rs
error: linking with `cc` failed: exit status: 1
[...]
= note: /usr/bin/ld: /tmp/crate_bin_lib/libmain1.rlib(main1.main1.707747aa-cgu.0.rcgu.o): in function `main':
main1.707747aa-cgu.0:(.text.main+0x0): multiple definition of `main'; main2.main2.02a148fe-cgu.0.rcgu.o:main2.02a148fe-cgu.0:(.text.main+0x0): first defined here
collect2: error: ld returned 1 exit status
```
|
|
Suggest copying trait associated type bounds on lifetime error
Closes #92033
Kind of the most simple suggestion to make - we don't try to be fancy. Turns out, it's still pretty useful (the couple existing tests that trigger this error end up fixed - for this error - upon applying the fix).
r? ``@estebank``
cc ``@nikomatsakis``
|
|
rustdoc: Collect traits in scope for lang items
Inherent impls on primitive types are not included in the list of all inherent impls in the crate (`inherent_impls_in_crate_untracked`), they are taken from the list of lang items instead, but such impls can also be inlined by rustdoc, e.g. if something derefs to a primitive type.
r? `@camelid`
Fixes https://github.com/rust-lang/rust/issues/93698
|
|
|
|
Revert #91403
fixes #94004
r? `@pnkfelix` `@cjgillot`
|
|
|
|
|
|
Fix ICE when using Box<T, A> with pointer sized A
Fixes #78459
Note that using `Box<T, A>` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.
|
|
Generate list instead of div items in sidebar
Fixes #92986.
Surprisingly, we didn't have much CSS for this...
[Demo](https://rustdoc.crud.net/imperio/links-in-sidebar/std/index.html).
r? `@jsha`
|
|
Update tracking issue numbers for inline assembly sub-features
The main tracking issue for inline assembly is [closed](https://github.com/rust-lang/rust/issues/72016#issuecomment-1022332954), further tracking of the remaining sub-features has been moved to separate tracking issues.
|
|
|
|
This reverts commit 3cfa4def7c87d571bd46d92fed608edf8fad236e, reversing
changes made to 5d8767cb229b097fedb1dd4bd9420d463c37774f.
|
|
to avoid panic for invalid Unicode scalar values
|
|
Upgrade to LLVM 14
LLVM patch state:
* [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported.
* [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017.
* [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream.
* [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported.
* [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream.
* [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream.
* [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport.
* [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream.
* [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream.
* [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream.
* [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856.
Release timeline:
* LLVM 14.0.0 final planned for Mar 15.
* Rust 1.60.0 planned for Apr 7.
Compile-time:
* https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864
* A slight improvement on average, though no big changes either way.
* There are some larger max-rss improvements.
r? `@ghost`
|
|
danielhenrymantilla:diagnostics/union-drop-suggest-copy-bound-alternative, r=davidtwco
[diagnostics] Add mentions to `Copy` types being valid for `union` fields
This came up from some user on Discord which was using a `T : PrimitiveInt` generic type, and they wanted to use in a `union`. Rather than adding a `Copy` bound, they started pondering about the `ManuallyDrop<T>` road, and how to correctly use `unsafe` to perform the drops.
<img width="648" alt="Screen Shot 2022-02-15 at 22 28 34" src="https://user-images.githubusercontent.com/9920355/154152496-8f9be74b-ad59-4724-8f9e-48b446774e06.png">
- [Discord link](https://discord.com/channels/442252698964721669/443150878111694848/943092778534072320)
So, it seemed like the error message for types with potential drop glue on `union` fields could be improved to also mention the `Copy` alternative, since in many cases where `union`s are concerned, people are dealing with PODs / `Copy` types anyways 🙂
___
``@rustbot`` modify labels: +A-diagnostics +D-terse
|
|
Correctly mark the span of captured arguments in `format_args!()`
It should not include the braces, or misspelling suggestions will be wrong.
Fixes #94010.
|
|
r=petrochenkov
Do not suggest "is a function" for free variables
Part of #82323
|
|
r=davidtwco
Fix suggestion to slice if scurtinee is a reference to `Result` or `Option`
Fixes https://github.com/rust-lang/rust/pull/91343#issuecomment-1037718339 and https://github.com/rust-lang/rust/pull/91343#discussion_r761466979.
|
|
Suggest deriving required supertraits
closes https://github.com/rust-lang/rust/issues/91550
I chose to just hardcode handling for PartialOrd and PartialEq because that should be robust enough and I dont know how to go about doing it generically
r? rust-lang/diagnostics
|
|
Destabilize cfg(target_has_atomic_load_store = ...)
This was not intended to be stabilized yet.
This keeps the cfg_target_has_atomic feature gate name since compiler-builtins otherwise depends on it and I'd rather not try to manage a bump across a crates.io published repository given the time-sensitivity here (we need to land this quickly to avoid a beta backport).
Closes https://github.com/rust-lang/rust/issues/32976
r? `@Amanieu`
|
|
|
|
The format of the remark changed slightly.
|
|
|
