| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add test for old compiler ICE when using `Borrow`
The original issue was caused by implementing `Borrow` on a local type and using the tokio-reactor crate which had this impl: https://github.com/tokio-rs/tokio/blob/tokio-0.1.4/tokio-reactor/src/poll_evented.rs#L547-L577
This causes an ICE on Rust 1.27.0:
```console
$ RUSTUP_TOOLCHAIN=1.27.0 rustc src/test/ui/issues/issue-50687-ice-on-borrow.rs
error: internal compiler error: librustc/traits/structural_impls.rs:180: impossible case reached
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:554:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.27.0 (3eda71b00 2018-06-19) running on x86_64-apple-darwin
```
Closes #50687
|
|
Fix confusing error message for comma typo in multiline statement
Fixes #72253. Expands on the issue with a colon typo check.
r? @estebank
cc @ehuss
|
|
confusing diagnostics, issue #72253
add test for confusing error message, issue-72253
remove is_multiline check, refactor to self.expect(&token:Semi)
update issue-72253 tests
return Ok
|
|
r=davidtwco
Allow unlabeled breaks from desugared `?` in labeled blocks
`?` is desugared into a `break` targeting the innermost `try` scope in which it resides. The `break` however will not have a label. https://github.com/rust-lang/rust/blob/master/src/librustc_ast_lowering/expr.rs#L1560
Since the `target` of the `break` is known, the compiler should not complain about an unlabeled jump for `break`s desugared from `?`.
Closes https://github.com/rust-lang/rust/issues/72483
|
|
Use correct function for detecting `const fn` in unsafety checking
Resolves #72394.
|
|
Warn about unused crate deps
Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`.
Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`.
If a crate has multiple aliases (eg using `foo = { package = "bar" }` in `Cargo.toml`), then it will warn about each unused alias.
This does not consider crate added by some other means than `--extern`, including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this).
Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates, causing spurious warnings. As a result, this lint is "allow" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.
|
|
add a lint against references to packed fields
Creating a reference to an insufficiently aligned packed field is UB and should be disallowed, both inside and outside of `unsafe` blocks. However, currently there is no stable alternative (https://github.com/rust-lang/rust/issues/64490) so all we do right now is have a future incompatibility warning when doing this outside `unsafe` (https://github.com/rust-lang/rust/issues/46043).
This adds an allow-by-default lint. @retep998 suggested this can help early adopters avoid issues. It also means we can then do a crater run where this is deny-by-default as suggested by @joshtriplett.
I guess the main thing to bikeshed is the lint name. I am not particularly happy with "packed_references" as it sounds like the packed field has reference type. I chose this because it is similar to "safe_packed_borrows". What about "reference_to_packed" or "unaligned_reference" or so?
|
|
This will print a diagnostic for crates which are mentioned as `--extern`
arguments on the command line, but are never referenced from the source.
This diagnostic is controlled by `-Wunused-crate-dependencies` or
`#![warn(unused_crate_dependencies)]` and is "allow" by default.
There are cases where certain crates need to be linked in but are not
directly referenced - for example if they are providing symbols for C
linkage. In this case the warning can be suppressed with
`use needed_crate as _;`.
Thanks to @petrochenkov for simplified core.
Resolves issue #57274
|
|
Fix bug in shebang handling
Shebang handling was too agressive in stripping out the first line in cases where it is actually _not_ a shebang, but instead, valid rust (#70528). This is a second attempt at resolving this issue (the first attempt was reverted, for, among other reasons, causing an ICE in certain cases (#71372, #71471).
The behavior is now codified by a number of UI tests, but simply:
For the first line to be a shebang, the following must all be true:
1. The line must start with `#!`
2. The line must contain a non-whitespace character after `#!`
3. The next character in the file, ignoring comments & whitespace must not be `[`
I believe this is a strict superset of what we used to allow, so perhaps a crater run is unnecessary, but probably not a terrible idea.
Fixes #70528
|
|
Fix ice-#72442
Closes #72442
Closes #72426
r? @oli-obk
|
|
add regression tests for stalled_on const vars
closes #70180
Afaict this has been fixed sometime after #70213
`trait_ref_type_vars` correctly adds const infers and I did not find any remaining `FIXME`s which correspond to this issue.
https://github.com/rust-lang/rust/blob/7c59a81a5fcbaaca311f744cd7c68d99bfbb05d3/src/librustc_trait_selection/traits/fulfill.rs#L555-L557
Added both examples from the issue as regression tests and renamed `trait_ref_type_vars` -> `trait_ref_infer_vars`.
r? @eddyb
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #72153 (exhaustively check `ty::Kind` during structural match checking)
- #72308 (Emit a better diagnostic when function actually has a 'self' parameter)
- #72560 (Enable `glacier` command via triagebot)
- #72567 (Clean up E0608 explanation)
Failed merges:
r? @ghost
|
|
Emit a better diagnostic when function actually has a 'self' parameter
Fixes #66898
When we are unable to resolve a reference to `self`, we current assume
that the containing function doesn't have a `self` parameter, and
emit an error message accordingly.
However, if the reference to `self` was created by a macro invocation,
then resolution will correctly fail, due to hygiene. In this case, we
don't want to tell the user that the containing fuction doesn't have a
'self' paramter if it actually has one.
This PR checks for the precense of a 'self' parameter, and adjusts the
error message we emit accordingly.
TODO: The exact error message we emit could probably be improved. Should
we explicitly mention hygiene?
|
|
exhaustively check `ty::Kind` during structural match checking
This was prone to errors as we may forget new kinds in the future.
I am also not yet sure about some kinds.
`ty::GeneratorWitness(..) | ty::Infer(_) | ty::Placeholder(_) | ty::UnnormalizedProjection(..) | ty::Bound(..)` might be unreachable here.
We may want to forbid `ty::Projection`, similar to `ty::Param`.
`ty::Opaque` seems fine afaict, should not be possible in a match atm.
I believe `ty::Foreign` should not be structurally match, as I don't even know what
that would actually mean.
r? @pnkfelix cc @eddyb
|
|
Shebang handling was too agressive in stripping out the first line in cases where it is actually _not_ a shebang, but instead, valid rust (#70528). This is a second attempt at resolving this issue (the first attempt was flawed, for, among other reasons, causing an ICE in certain cases (#71372, #71471).
The behavior is now codified by a number of UI tests, but simply:
For the first line to be a shebang, the following must all be true:
1. The line must start with `#!`
2. The line must contain a non whitespace character after `#!`
3. The next character in the file, ignoring comments & whitespace must not be `[`
I believe this is a strict superset of what we used to allow, so perhaps a crater run is unnecessary, but probably not a terrible idea.
|
|
Remove dangling COPYRIGHT references
Missed in 2a663555ddf36f6b041445894a8c175cd1bc718c.
r? @Mark-Simulacrum
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #72284 (Remove `macro_defs` map)
- #72393 (Rewrite `Parser::collect_tokens`)
- #72528 (Fix typo in doc comment.)
Failed merges:
r? @ghost
|
|
r=petrochenkov
Rewrite `Parser::collect_tokens`
The previous implementation did not work when called on an opening
delimiter, or when called re-entrantly from the same `TokenCursor` stack
depth.
I'm not sure how to test this apart from https://github.com/rust-lang/rust/pull/72287
|
|
Rollup of 2 pull requests
Successful merges:
- #72388 (Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`)
- #72517 (small select cleanup)
Failed merges:
r? @ghost
|
|
Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
Fixes #68430
When comparing the captured and re-parsed `TokenStream` for a `TokenKind::Interpolated`, we currently treat any nested `TokenKind::Interpolated` tokens as unequal. If a `TokenKind::Interpolated` token shows up in the captured `TokenStream` due to a `macro_rules!` expansion, we will throw away the captured `TokenStream`, losing span information.
This PR recursively invokes `nt_to_tokenstream` on nested `TokenKind::Interpolated` tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original captured `TokenStream` (with span information).
This requires all of the `probably_equal_for_proc_macro` methods to be moved from `librustc_ast` to `librustc_parse` so that they can call `nt_to_tokenstream`.
|
|
Remove ReScope
`ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully.
cc #68261
r? @nikomatsakis
|
|
Preserve substitutions when making trait obligations for suggestions
Resolves #71394.
I *think* `map_bound_ref` is correct here. In any case, I think a lot of the diagnostic code is using `skip_binder` more aggressively than it should be, so I doubt that this is worse than the status quo. The assertion that `new_self_ty` has no escaping bound vars should be enough.
r? @estebank
cc @nikomatsakis Is the call to `skip_binder` on line 551 (and elsewhere in this file) appropriate? https://github.com/rust-lang/rust/blob/46ec74e60f238f694b46c976d6217e7cf8d4cf1a/src/librustc_trait_selection/traits/error_reporting/suggestions.rs#L537-L565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize process_set_argv0 feature for Unix
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
|
|
Fix suggestion to borrow in struct
The corresponding issue is #71136.
The compiler suggests that borrowing `the_foos` might solve the problem. This is obviously incorrect.
```
struct Foo(u8);
#[derive(Clone)]
struct FooHolster {
the_foos: Vec<Foo>,
}
```
I propose as fix to check if there is any colon in the span. However, there might a case where `my_method(B { a: 1, b : foo })` would be appropriate to show a suggestion for `&B ...`. To fix that too, we can simply check if there is a bracket in the span. This is only possible because both spans are different.
Issue's span: `the_foos: Vec<Foo>`
other's span: `B { a : 1, b : foo }`
|
|
Break tokens before checking if they are 'probably equal'
Fixes #68489
Fixes #70987
When checking two `TokenStreams` to see if they are 'probably equal',
we ignore the `IsJoint` information associated with each `TokenTree`.
However, the `IsJoint` information determines whether adjacent tokens
will be 'glued' (if possible) when construction the `TokenStream` - e.g.
`[Gt Gt]` can be 'glued' to `BinOp(Shr)`.
Since we are ignoring the `IsJoint` information, 'glued' and 'unglued'
tokens are equivalent for determining if two `TokenStreams` are
'probably equal'. Therefore, we need to 'unglue' all tokens in the
stream to avoid false negatives (which cause us to throw out the cached
tokens, losing span information).
|
|
|
|
The previous implementation did not work when called on an opening
delimiter, or when called re-entrantly from the same `TokenCursor` stack
depth.
|
|
|
|
r=tmandry
Clean up logic around live locals in generator analysis
Resolves #69902. Requires #71893.
I've found it difficult to make changes in the logic around live locals in `generator/transform.rs`. It uses a custom dataflow analysis, `MaybeRequiresStorage`, that AFAICT computes whether a local is either initialized or borrowed. That analysis is using `before` effects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday.
This PR replaces `MaybeRequiresStorage` with a combination of the existing `MaybeBorrowedLocals` and a new `MaybeInitializedLocals`. `MaybeInitializedLocals` is just `MaybeInitializedPlaces` with a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic in `compute_storage_conflicts` and `locals_live_across_suspend_points`.
This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the `mixed_sizes` future couldn't be 5K. It went from 7K to 6K in this PR.
r? @jonas-schievink @tmandry
|
|
Rollup of 7 pull requests
Successful merges:
- #72055 (Intern predicates)
- #72149 (Don't `type_of` on trait assoc ty without default)
- #72347 (Make intra-link resolve links for both trait and impl items)
- #72350 (Improve documentation of `slice::from_raw_parts`)
- #72382 (Show default values for debug-assertions & debug-assertions-std)
- #72421 (Fix anchor display when hovering impl)
- #72425 (fix discriminant_value sign extension)
Failed merges:
r? @ghost
|
|
Don't `type_of` on trait assoc ty without default
Fix #72076.
|
|
De-abuse TyKind::Error in exhaustiveness checking
Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866.
In order to remove the use of `TyKind::Error`, I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however, since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct, that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model.
As usual, I tried to separate commits that shuffle code around from commits that require more thought to review.
cc @varkor @Centril
|
|
Experimentally add `ffi_const` and `ffi_pure` extern fn attributes
Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`.
Rebased version of #58327 by @gnzlbg with the following changes:
- Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with https://github.com/rust-lang/rust/pull/58327#issuecomment-462718772 and this nicely aligns with `ffi_returns_twice`
- (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR
r? @hanna-kruppe
|
|
Dumb NRVO
This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.
I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.
r? @ghost
|
|
Use `T`'s discriminant type in `mem::Discriminant<T>` instead of `u64`.
fixes #70509
Adds the lang-item `discriminant_kind`.
Updates the function signature of `intrinsics::discriminant_value`.
Adds the *probably permanently unstable* trait `DiscriminantKind`.
`mem::Discriminant` should now be smaller in some cases.
r? @ghost
|
|
|
|
|
