| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=petrochenkov
Rename clashing_extern_decl to clashing_extern_declarations.
Rename clashing_extern_decl to clashing_extern_declarations to bring in-line with lint naming conventions.
Fixes #73802.
r? @petrochenkov
|
|
Add some `const_compare_raw_pointers`-related regression tests
Closes #71381
Closes #71382
Closes #71611
Closes #72352
r? @oli-obk, the author of #73398
|
|
Make liveness more precise for assignments to fields
Previously, we were too conservative and `x.field = 4` was treated as a "use" of `x`. Now it neither kills `x` (since other fields of `x` may still be live) nor marks it as live.
cc @jonas-schievink, who ran into this problem.
|
|
errors: use `-Z terminal-width` in JSON emitter
This PR makes the JSON emitter use `-Z terminal-width` in the "rendered" field of the JSON output.
r? @estebank
|
|
Explain move errors that occur due to method calls involving `self` (take two)
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
|
|
Adds a clearer message for when the async keyword is missing from a f…
…unction
This is a somewhat simple fix for #66731.
Under the current version of Rust, if a user has a rust file that looks like this:
```rust
fn boo (){}
async fn foo() {
boo().await;
}
fn main() {
}
```
And they attempt to run it, they will receive an error message that looks like this:
```bash
error: incorrect use of `await` --> test.rs:4:14 | 4 | boo.await(); | ^^ help: `await` is not a method call, remove the parentheses error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied --> test.rs:4:5 | 4 | boo.await(); | ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`.
```
This is not very clear.
With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:
```bash
error[E0277]: `()` is not a future.
--> test.rs:4:5
|
4 | boo().await;
| ^^^^^^^^^^^ `()` is not a future
|
= help: the trait `std::future::Future` is not implemented for `()`
= note: required by `std::future::Future::poll`
```
In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](https://github.com/rust-lang/rust/issues/66731#issuecomment-644394287). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
|
Prepare for LLVM 11
These are just the code changes needed to build with the current LLVM master (version 11).
r? @nikic
|
|
Also, run RustFmt on the clashing_extern_fn test case and update
stderrs.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #72771 (Warn if linking to a private item)
- #72937 (Fortanix SGX target libunwind build process changes)
- #73485 (Perform obligation deduplication to avoid buggy `ExistentialMismatch`)
- #73529 (Add liballoc impl SpecFromElem for i8)
- #73579 (add missing doc links)
- #73627 (Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators)
- #73691 (Bootstrap: detect Windows based on sys.platform)
- #73694 (Document the Self keyword)
- #73718 (Document the super keyword)
- #73728 (Document some invariants correctly/more)
- #73738 (Remove irrelevant comment)
- #73765 (Remove blank line)
Failed merges:
r? @ghost
|
|
rustc_lexer: Simplify shebang parsing once more
Fixes https://github.com/rust-lang/rust/issues/73250 (beta regression)
Treat any line starting with `!#` as a shebang candidate, not only lines with something non-whitespace.
This way we no longer need to define what `is_whitespace` means ([Linux shebang whitespace](https://github.com/torvalds/linux/blob/master/fs/binfmt_script.c), ASCII whitespace, Rust lexer whitespace, etc), which is nice.
This change makes some invalid Rust code valid (see the regression above), but still never interprets a fragment of valid Rust code as a shebang.
(This PR also removes one duplicate test.)
|
|
Perform obligation deduplication to avoid buggy `ExistentialMismatch`
Address #59326.
|
|
Warn if linking to a private item
Closes https://github.com/rust-lang/rust/issues/72769
r? @GuillaumeGomez
|
|
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
|
|
|
|
|
|
This commit makes the JSON emitter use `-Z terminal-width` in the
"rendered" field of the JSON output.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Show the values and computation that would overflow a const evaluation or propagation
Fixes #71134
In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics.
cc @shepmaster
The way this is implemented it is also fairly easy to do the same for overflow panics at runtime, but that should be done in a separate PR since it may have runtime performance implications.
|
|
- Pass around document_private a lot more
- Add tests
+ Add tests for intra-doc links to private items
+ Add ignored tests for warnings in reference links
|
|
propagation
|
|
Update Chalk to 0.14
Not a ton here. Notable changes:
- Update to `0.14.0`
- New dependency on `tracing`, in `librustc_traits` only
- `FnAbi` from Chalk is `rustc_target::spec::abi::Abi`
- `Dynamic` actually lowers region
- Actually lower closures, with some tests. This doesn't 100% work, but can't confirm that's *only* because of closure lowering.
- Use `FxIndexSet` instead of `FxHashSet` in `chalk_fulfill`, which seems to have fixed the non-deterministic test error ordering. Guess we'll see on CI
- Actually implement `opaque_ty_data`, though I don't think this is sufficient for tests for them (I haven't added any)
- Uncomment some of the chalk tests that now work
r? @nikomatsakis
|
|
Omit DW_AT_linkage_name when it is the same as DW_AT_name
The DWARF standard suggests that it might be useful to include
`DW_AT_linkage_name` when it is *distinct* from the identifier name.
Fixes #46487.
Fixes #59422.
|
|
Rollup of 14 pull requests
Successful merges:
- #72617 (Add a fast path for `std::thread::panicking`.)
- #72738 (Self contained linking option)
- #72770 (Implement mixed script confusable lint.)
- #73418 (Add unstable `core::mem::variant_count` intrinsic)
- #73460 (Emit line info for generator variants)
- #73534 (Provide suggestions for some moved value errors)
- #73538 (make commented examples use valid syntax, and be more consistent )
- #73581 (Create 0766 error code)
- #73619 (Document the mod keyword)
- #73621 (Document the mut keyword)
- #73648 (Document the return keyword)
- #73673 (Fix ptr doc warnings.)
- #73674 (Tweak binop errors)
- #73687 (Clean up E0701 explanation)
Failed merges:
- #73708 (Explain move errors that occur due to method calls involving `self` (take two))
r? @ghost
|
|
|
|
Tweak binop errors
* Suggest potentially missing binop trait bound (fix #73416)
* Use structured suggestion for dereference in binop
|
|
Create 0766 error code
|
|
Provide suggestions for some moved value errors
When encountering an used moved value where the previous move happened
in a `match` or `if let` pattern, suggest using `ref`. Fix #63988.
When encountering a `&mut` value that is used in multiple iterations of
a loop, suggest reborrowing it with `&mut *`. Fix #62112.
|
|
Emit line info for generator variants
Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually, this could grow into an "async stack trace" feature of sorts. While no debugger support this for Rust today, this PR adds the debuginfo necessary for that support to exist.
[This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet:
```
0x00000986: DW_TAG_variant
DW_AT_discr_value (0x03)
0x00000988: DW_TAG_member
DW_AT_name ("3")
DW_AT_type (0x000009bc "Suspend0")
DW_AT_decl_file ("/home/tmandry/code/playground/generator-simple.rs")
DW_AT_decl_line (6)
DW_AT_alignment (8)
DW_AT_data_member_location (0x00)
```
The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await), because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically, but that can be done independently of this change.)
Debuggers don't know how to use this kind of info yet. However, we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb.
r? @oli-obk
cc @eddyb @jonas-schievink
Part of #73524.
|
|
Add unstable `core::mem::variant_count` intrinsic
Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`.
I've shown this to a couple of people and they invariably ask 'why on earth?', but there's actually a very neat use case:
At the moment, if you want to create an opaque array type that's indexed by an `enum` with one element for each variant, you either have to hard-code the number of variants, add a `LENGTH` variant or use a `Vec`, none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic, it becomes possible to write the following:
```rust
#[derive(Copy, Clone)]
enum OpaqueIndex {
A = 0,
B,
C,
}
struct OpaqueVec<T>(Box<[T; std::mem::num_variants::<OpaqueIndex>()]>);
impl<T> std::ops::Index<OpaqueIndex> for OpaqueVec<T> {
type Output = T;
fn index(&self, idx: OpaqueIndex) -> &Self::Output {
&self.0[idx as usize]
}
}
```
(We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.)
|
|
Implement mixed script confusable lint.
This implements the mixed script confusable lint defined in RFC 2457.
This is blocked on #72069 and https://github.com/unicode-rs/unicode-security/pull/13, and will need a Cargo.toml version bump after those are resolved.
The lint message warning is sub-optimal for now. We'll need a mechanism to properly output `AugmentScriptSet` to screen, this is to be added in `unicode-security` crate.
r? @Manishearth
|
|
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
|
Print environment variables accessed by rustc as special comments into depinfo files
So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes.
---
I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo.
Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074.
Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts.
---
Description:
- depinfo files are extended with special comments containing info about environment variables accessed during compilation.
- Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`.
- Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`).
- `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends.
FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488
Closes https://github.com/rust-lang/rust/issues/70517
Closes https://github.com/rust-lang/rust/issues/40364
Closes https://github.com/rust-lang/rust/issues/44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.
r? @ehuss
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #72700 (`improper_ctypes_definitions` lint)
- #73516 (Allow dynamic linking for iOS/tvOS targets)
- #73616 (Liballoc minor hash import tweak)
- #73634 (Add UI test for issue 73592)
- #73688 (Document the self keyword)
- #73698 (Add procedure for prioritization notifications on Zulip)
Failed merges:
r? @ghost
|
|
|
|
When encountering an used moved value where the previous move happened
in a `match` or `if let` pattern, suggest using `ref`. Fix #63988.
When encountering a `&mut` value that is used in multiple iterations of
a loop, suggest reborrowing it with `&mut *`. Fix #62112.
|
|
Add UI test for issue 73592
It happens that #72280 accidentally fixed a bug which is later discovered in #73592. This PR adds a UI test to prevent future regression.
Closes #73592
|
|
r=lcnr,varkor
`improper_ctypes_definitions` lint
Addresses #19834, #66220, and #66373.
This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern "C" fn` definitions in addition to `extern "C" {}` declarations, this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern "C" fn` definitions.
In addition, the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220).
There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take, but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing.
cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220), @SimonSapin (#65134 caused problems for Servo, want to make sure that this PR doesn't)
|
|
Verify that the binop trait *is* implemented for the types *if* all the
involved type parameters are replaced with fresh inferred types. When
this is the case, it means that the type parameter was indeed missing a
trait bound. If this is not the case, provide a generic `note` refering
to the type that doesn't implement the expected trait.
|
|
Fixes #70718
This commit allows making associated items (e.g. associated functions
and types) into lang items via the `#[lang]` attribute. This allows such
items to be accessed directly, rather than by iterating over the parent
item's associated items.
I've added `FnOnce::Output` as a lang item, and updated one old usage to
use the new lang item. The remaining uses can be updated separately.
|
|
This keeps FileCheck from tripping over unimportant differences in
codegen.
|
|
|
|
..which doesn't use variant types.
|
|
Don't be so reliant on particular line ordering (though FileCheck makes
this hard in general, IMO). Also disable for MSVC.
|
|
|
|
|
