Point out missing if conditional
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
Fix#13483.
Generate builtin impls for `Clone`
This fixes a long-standing ICE and limitation where some builtin types implement `Copy` but not `Clone` (whereas `Clone` is a super trait of `Copy`).
However, this PR has a few side-effects:
* `Clone` is now marked as a lang item.
* `[T; N]` is now `Clone` if `T: Clone` (currently, only if `T: Copy` and for `N <= 32`).
* `fn foo<'a>() where &'a mut (): Clone { }` won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace `Clone` by `Copy` in this example). Of course this function is unusable anyway, an error would pop as soon as it is called.
Hence, I'm wondering wether this PR would need an RFC...
Also, cc-ing @nikomatsakis, @arielb1.
Related issues: #28229, #24000.
syntax: Relax path grammar
TLDR: Accept the disambiguator `::` in "type" paths (`Type::<Args>`), accept the disambiguator `::` before parenthesized generic arguments (`Fn::(Args)`).
The "turbofish" disambiguator `::<>` in expression paths is a necessary evil required for path parsing to be both simple and to give reasonable results.
Since paths in expressions usually refer to values (but not necessarily, e.g. `Struct::<u8> { field: 0 }` is disambiguated, but refers to a type), people often consider `::<>` to be inherent to *values*, and not *expressions* and want to write disambiguated paths for values even in contexts where disambiguation is not strictly necessary, for example when a path is passed to a macro `m!(Vec::<i32>::new)`.
The problem is that currently, if the disambiguator is not *required*, then it's *prohibited*. This results in confusion - see https://github.com/rust-lang/rust/issues/41740, https://internals.rust-lang.org/t/macro-path-uses-novel-syntax/5561.
This PR makes the disambiguator *optional* instead of prohibited in contexts where it's not strictly required, so people can pass paths to macros in whatever form they consider natural (e.g. disambiguated form for value paths).
This PR also accepts the disambiguator in paths with parenthesized arguments (`Fn::(Args)`) for consistency and to simplify testing of stuff like https://github.com/rust-lang/rust/pull/41856#issuecomment-301219194.
Closes https://github.com/rust-lang/rust/issues/41740
cc @rust-lang/lang
r? @nikomatsakis
rustc: Add `Local` to the HIR map of parents
When walking parents for lints we want to be sure to hit `let` statements which
can have attributes, so hook up these statements in the HIR map.
Closes#43910
When walking parents for lints we want to be sure to hit `let` statements which
can have attributes, so hook up these statements in the HIR map.
Closes#43910
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
rustc: Fix `unknown_lints` next to an unknown lint
The lint refactoring in #43522 didn't account for `#[allow(unknown_lints)]`
happening at the same node as an unknown lint itself, so this commit updates the
handling to ensure that the local set of lint configuration being built is
queried before looking at the chain of lint levels.
Closes#43809
Fix ICE with elided lifetimes in return type of foreign functions
cc https://github.com/rust-lang/rust/issues/43567
This is for a preliminary crater/cargobomb run.
Lifetime elision in foreign functions now works exactly like in other functions or function-like entities.
If the breakage is significant, I'll have to partially revert https://github.com/rust-lang/rust/pull/43543 (all the stuff that was required for dealing with late bound lifetimes in this position).
r? @eddyb
emit StorageLive for box temporaries
We started emitting StorageDead, so we better emit the corrseponding
StorageLive to avoid problems.
cc #43772solson/miri#303
remove the "defaulted unit" type bit during writeback
The defaulted unit bit is only relevant for the surrounding inference
context, and can cause trouble, including spurious lints and ICEs,
outside of it.
Fixes#43853.
r? @eddyb
Fix "Mis-calculated spans" errors from `-Z save-analysis` + refactoring
Removed the path span extraction methods from `SpanUtils`:
* spans_with_brackets
* spans_for_path_segments
* spans_for_ty_params
Use the `span` fields in `PathSegment` and `TyParam` instead.
(Note that since it processes `ast::Path` not a qualified path (`hir::QPath` / `ast::QSelf`), UFCS path will be flattened: `<Foo as a:🅱️:c::Trait>::D::E::F::g` will be seen as `a:🅱️:c::Trait::D::E::F::g`.)
Fix#43796. Close#41478.
r? @nrc
The defaulted unit bit is only relevant for the surrounding inference
context, and can cause trouble, including spurious lints and ICEs,
outside of it.
Fixes#43853.
ast_validation: forbid "nonstandard" literal patterns
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
Fixes#43250.
beta-nominating because regression.
r? @eddyb
Fix for issue #39827
*Cause of the issue*
While preparing for `trans_intrinsic_call()` invoke arguments are processed with `trans_argument()` method which excludes zero-sized types from argument list (to be more correct - all arguments for which `ArgKind` is `Ignore` are filtered out). As result `volatile_store()` intrinsic gets one argument instead of expected address and value.
*How it is fixed*
Modification of the `trans_argument()` method may cause side effects, therefore change was implemented in `volatile_store()` intrinsic building code itself. Now it checks function signature and if it was specialised with zero-sized type, then emits `C_nil()` instead of accessing non-existing second argument.
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
Fixes#43250.
The lint refactoring in #43522 didn't account for `#[allow(unknown_lints)]`
happening at the same node as an unknown lint itself, so this commit updates the
handling to ensure that the local set of lint configuration being built is
queried before looking at the chain of lint levels.
Closes#43809
Fix include! in doc tests
By making the path relative to the current file.
Fixes#43153
[breaking-change] - if you use `include!` inside a doc test, you'll need to change the path to be relative to the current file rather than relative to the working directory.
Fix unused_result lint triggering when a function returns `()`, `!` or an empty enum
Also added a test to prevent this from happening again.
Fixes#43806
Expose all OS-specific modules in libstd doc.
1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.
2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.
3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.
Fixes#24658 (Does _not_ fully implement #1998).
- adds handling of zero-sized types for volatile_store.
- adds type size checks and warnigns for other volatile intrinsics.
- adds a test to check warnings emitting.
Cause of the issue
While preparing for trans_intrinsic_call() invoke arguments are
processed with trans_argument() method which excludes zero-sized types
from argument list (to be more correct - all arguments for which
ArgKind is Ignore are filtered out). As result volatile_store() intrinsic
gets one argument instead of expected address and value.
How it is fixed
Modification of the trans_argument() method may cause side effects,
therefore change was implemented in volatile_store() intrinsic building
code itself. Now it checks function signature and if it was specialised
with zero-sized type, then emits C_nil() instead of accessing
non-existing second argument.
Additionally warnings are added for all volatile operations which are
specialised with zero-sized arguments. In fact, those operations are omitted
in LLVM backend if no memory affected at all, e.g. number of elements
is zero or type is zero-sized. This was not explicitly documented before
and could lead to potential issues if developer expects volatile behaviour,
but type has degraded to zero-sized.
