| Age | Commit message (Collapse) | Author | Lines |
|---|
|
When encountering the following typo:
```rust
a: loop { break 'a; }
```
provide an appropriate suggestion.
|
|
|
|
|
|
Point at loop head on invalid `break expr`.
Suggest removing `expr` or using label if available.
|
|
When encountering a name `a` that isn't resolved, but a label `'a` is
found in the current ribs, only suggest `'a` if this name is the value
expression of a `break` statement.
Solve FIXME.
|
|
|
|
Force token collection to run when parsing nonterminals
Fixes #81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #79655 (Add Vec visualization to understand capacity)
- #80172 (Use consistent punctuation for 'Prelude contents' docs)
- #80429 (Add regression test for mutual recursion in obligation forest)
- #80601 (Improve grammar in documentation of format strings)
- #81046 (Improve unknown external crate error)
- #81178 (Visit only terminators when removing landing pads)
- #81179 (Fix broken links with `--document-private-items` in the standard library)
- #81184 (Remove unnecessary `after_run` function)
- #81185 (Fix ICE in mir when evaluating SizeOf on unsized type)
- #81187 (Fix typo in counters.rs)
- #81219 (Document security implications of std::env::temp_dir)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix ICE in mir when evaluating SizeOf on unsized type
Not quite ready yet. This tries to fix #80742 as discussed on [Zulip topic][1],
by using `delay_span_bug`.
I don't understand what `delay_span_bug` does. It seems like my error message
is never used. With this patch, in this program:
```rust
#![allow(incomplete_features)]
#![feature(const_evaluatable_checked)]
#![feature(const_generics)]
use std::fmt::Debug;
use std::marker::PhantomData;
use std::mem::size_of;
struct Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
_phantom: PhantomData<T>,
buf: [u8; size_of::<T>() + 1],
}
impl<T> Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
pub fn new(val: T) -> Inline<T> {
todo!()
}
}
fn main() {
let dst = Inline::<dyn Debug>::new(0); // line 27
}
```
these errors are printed, both for line 27 (annotated line above):
- "no function or associated item named `new` found for struct `Inline<dyn
Debug>` in the current scope"
- "the size for values of type `dyn Debug` cannot be known at compilation time"
Second error makes sense, but I'm not sure about the first one and why it's
even printed.
Finally, I'm not sure about the span passing in `const_eval`.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Help.20fixing.20.2380742
|
|
Improve unknown external crate error
This improves error messages when unknown items in the crate root are encountered.
Fixes #63799
r? ```@estebank```
|
|
Add regression test for mutual recursion in obligation forest
Add regression test for #75860 with a slightly smaller example.
I was looking at what caused the issue and was surprised when it errors out on nightly, so I just added a regression test which should effectively close the issue, altho it would be nice to find the fix for reference.
Also I found that 80066 is not fixed by whatever fixed 75860.
|
|
|
|
Deprecate-in-future the constants superceded by RFC 2700
Successor to #78335, re-opened after addressing the issues tracked in #68490.
This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see #78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future).
With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696).
|
|
Currently, when a user uses a struct pattern to pattern match on
a tuple struct, the errors we emit generally suggest adding fields
using their field names, which are numbers. However, numbers are
not valid identifiers, so the suggestions, which use the shorthand
notation, are not valid syntax. This commit changes those errors
to suggest using the actual tuple struct pattern syntax instead,
which is a more actionable suggestion.
|
|
|
|
See https://github.com/rust-lang/rust/pull/81197 for what's going on
here; this is a temporary stopgap until someone has time to review the
proper fix.
|
|
Fixes #81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
|
|
Skip linking if it is not required
This allows to use `--emit=metadata,obj` and other metadata + non-link combinations.
Fixes #81117.
|
|
|
|
|
|
Fixes #80742
|
|
Rollup of 8 pull requests
Successful merges:
- #80382 (Improve search result tab handling)
- #81112 (Remove unused alloc::std::ops re-export.)
- #81115 (BTreeMap: prefer bulk_steal functions over specialized ones)
- #81147 (Fix structured suggestion for explicit `drop` call)
- #81161 (Remove inline script tags)
- #81164 (Fix typo in simplify.rs)
- #81166 (remove some outdated comments regarding debug assertions)
- #81168 (Fixes #81109 - Typo in pointer::wrapping_sub)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix structured suggestion for explicit `drop` call
|
|
Fix `unused_unsafe` label with `unsafe_block_in_unsafe_fn
Previously, the following code:
```rust
#![feature(unsafe_block_in_unsafe_fn)]
unsafe fn foo() {
unsafe { unsf() }
}
unsafe fn unsf() {}
```
Would give the following warning:
```
warning: unnecessary `unsafe` block
--> src/lib.rs:4:5
|
4 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
```
which doesn't point out that the block is in an `unsafe fn`.
Tracking issue: #71668
cc #79208
|
|
don't suggest erroneous trailing comma after `..`
In #76612, suggestions were added for missing fields in patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the last field. This resulted in the "if you don't care about missing fields" suggestion to recommend code with a trailing comma after the field ellipsis (`..,`), which is actually not legal ("`..` must be at the end and cannot have a trailing comma")!
Incidentally, the doc-comment on `error_unmentioned_fields` was using `you_cant_use_this_field` as an example field name (presumably copy-paste inherited from the description of Issue #76077), but the present author found this confusing, because unmentioned fields aren't necessarily unusable.
The suggested code in the diff this commit introduces to `destructuring-assignment/struct_destructure_fail.stderr` doesn't work, but it didn't work beforehand, either (because of the "found reserved identifier `_`" thing), so you can't really call it a regression; it could be fixed in a separate PR.
Resolves #78511.
r? `@davidtwco` or `@estebank`
|
|
Add suggestion for impl_candidates with E0283
Fix #42226
|
|
Stability oddity with const intrinsics
cc `@RalfJung`
In https://github.com/rust-lang/rust/pull/80699#discussion_r551495670 `@usbalbin` realized we accepted some intrinsics as `const` without a `#[rustc_const_(un)stable]` attribute. I did some digging, and that example works because intrinsics inherit their stability from their parents... including `#[rustc_const_(un)stable]` attributes. While we may want to fix that (not sure, wasn't there just a MCPed PR that caused this on purpose?), we definitely want tests for it, thus this PR adding tests and some fun tracing statements.
|
|
Apparently `tidy` has a hard limit of 2830 tests in the
`src/test/ui/issues/` directory, and this test hit that limit.
`src/test/ui/consts/` is probably a better location anyway.
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #81038 (Update Clippy)
- #81071 (rustc_parse_format: Fix character indices in find_skips)
- #81100 (prevent potential bug in `encode_with_shorthand`.)
- #81105 (Initialize a few variables directly)
- #81116 (ConstProp: Copy body span instead of querying it)
- #81121 (Avoid logging the whole MIR body in SimplifyCfg)
- #81123 (Update cmp.rs)
- #81125 (Add track_caller to .steal())
- #81128 (validation test: turn some const_err back into validation failures)
- #81131 (Edit rustc_middle::ty::cast docs)
- #81142 (Replace let Some(..) = with .is_some())
- #81153 (Remove unused linkcheck exceptions)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
validation test: turn some const_err back into validation failures
This resolves the problem I raised at https://github.com/rust-lang/rust/pull/78407#discussion_r556732926.
r? `@oli-obk`
|
|
rustc_parse_format: Fix character indices in find_skips
Fixes #81006
|
|
Feature-gate `pointer` and `reference` in intra-doc links
r? `@camelid`
Addresses (but does not close) https://github.com/rust-lang/rust/issues/80896.
|
|
|
|
|
|
|
|
Don't use posix_spawn_file_actions_addchdir_np on macOS.
There is a bug on macOS where using `posix_spawn_file_actions_addchdir_np` with a relative executable path will cause `posix_spawnp` to return ENOENT, even though it successfully spawned the process in the given directory.
`posix_spawn_file_actions_addchdir_np` was introduced in macOS 10.15 first released in Oct 2019. I have tested macOS 10.15.7 and 11.0.1.
Example offending program:
```rust
use std::fs;
use std::os::unix::fs::PermissionsExt;
use std::process::*;
fn main() {
fs::create_dir_all("bar").unwrap();
fs::create_dir_all("foo").unwrap();
fs::write("foo/foo.sh", "#!/bin/sh\necho hello ${PWD}\n").unwrap();
let perms = fs::Permissions::from_mode(0o755);
fs::set_permissions("foo/foo.sh", perms).unwrap();
let c = Command::new("../foo/foo.sh").current_dir("bar").spawn();
eprintln!("{:?}", c);
}
```
This prints:
```
Err(Os { code: 2, kind: NotFound, message: "No such file or directory" })
hello /Users/eric/Temp/bar
```
I wanted to open this PR to get some feedback on possible solutions. Alternatives:
* Do nothing.
* Document the bug.
* Try to detect if the executable is a relative path on macOS, and avoid using `posix_spawn_file_actions_addchdir_np` only in that case.
I looked at the [XNU source code](https://opensource.apple.com/source/xnu/xnu-6153.141.1/bsd/kern/kern_exec.c.auto.html), but I didn't see anything obvious that would explain the behavior. The actual chdir succeeds, it is something else further down that fails, but I couldn't see where.
EDIT: I forgot to mention, relative exe paths with `current_dir` in general are discouraged (see #37868). I don't know if #37868 is fixable, since normalizing it would change the semantics for some platforms. Another option is to convert the executable to an absolute path with something like joining the cwd with the new cwd and the executable, but I'm uncertain about that.
|
|
remote-test-server does not set the current_dir, and leaves it
as `/`.
|
|
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
|
|
Remove PredicateKind and instead only use Binder<PredicateAtom>
Originally brought up in https://github.com/rust-lang/rust/pull/76814#discussion_r546858171
r? `@lcnr`
|
|
- Only feature gate associated items
- Add docs to unstable book
|
|
|
|
Don't make tools responsible for checking unknown and renamed lints
Previously, clippy (and any other tool emitting lints) had to have their
own separate UNKNOWN_LINTS pass, because the compiler assumed any tool
lint could be valid. Now, as long as any lint starting with the tool
prefix exists, the compiler will warn when an unknown lint is present.
This may interact with the unstable `tool_lint` feature, which I don't entirely understand, but it will take the burden off those external tools to add their own lint pass, which seems like a step in the right direction to me.
- Don't mark `ineffective_unstable_trait_impl` as an internal lint
- Use clippy's more advanced lint suggestions
- Deprecate the `UNKNOWN_CLIPPY_LINTS` pass (and make it a no-op)
- Say 'unknown lint `clippy::x`' instead of 'unknown lint x'
This is tested by existing clippy tests. When https://github.com/rust-lang/rust/pull/80527 merges, it will also be tested in rustdoc tests. AFAIK there is no way to test this with rustc directly.
|
|
|
