| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Disallow ._ in float literal.
This patch makes lexer stop parsing number literals before `._`, as well as before `.a`. Underscore itself is still allowed like in `4_000_000.000_000_`.
Fixes a half part of #41723. The other is `""_`.
|
|
Include the crate's root module in save-analysis
r? @eddyb
|
|
This commit extends the current unused macro linter
to support directives like #[allow(unused_macros)]
or #[deny(unused_macros)] directly next to the macro
definition, or in one of the modules the macro is
inside. Before, we only supported such directives
at a per crate level, due to the crate's NodeId
being passed to session.add_lint.
We also had to implement handling of the macro's
NodeId in the lint visitor.
|
|
|
|
|
|
* Handles `b"…"`, `br#"…"#` and `...` for `quote_expr!()`.
* Refactored the match statement to allow it to complain loudly on any
unhandled token.
* Similarly, proc_macro's `quote!()` did not handle `br#"…"#` or `r#"…"#`,
so this commit fixes it too.
|
|
Rollup of 15 pull requests
- Successful merges: #41820, #41860, #41876, #41896, #41912, #41916, #41918, #41921, #41923, #41934, #41935, #41940, #41942, #41943, #41951
- Failed merges:
|
|
This is mostly removing stray ampersands, needless returns and lifetimes.
|
|
|
|
These are now no longer necessary with `-Z force-unstable-if-unmarked`
|
|
|
|
|
|
|
|
incr.comp.: Hash more pieces of crate metadata to detect changes there.
This PR adds incr. comp. hashes for non-`Entry` pieces of data in crate metadata.
The first part of it I like: `EntryBuilder` is refactored into the more generally applicable `IsolatedEncoder` which provides means of encoding something into metadata while also feeding the encoded data into an incr. comp. hash. We already did this for `Entry`, now we are doing it for various other pieces of data too, like the set of exported symbols and so on. The hashes generated there are persisted together with the per-`Entry` hashes and are also used for dep-graph dirtying the same way.
The second part of the PR I'm not entirely happy with: In order to make sure that we don't forget registering a read to the new `DepNodes` introduced here, I added the `Tracked<T>` struct. This struct wraps a value and requires a `DepNode` when accessing the wrapped value. This makes it harder to overlook adding read edges in the right places and works just fine.
However, crate metadata is already used in places where there is no `tcx` yet or even in places where no `cnum` has been assigned -- this makes it harder to apply this feature consistently or implement it ergonomically. The result is not too bad but there's a bit more code churn and a bit more opportunity to get something wrong than I would have liked. On the other hand, wrapping things in `Tracked<T>` already has revealed some bugs, so there's definitely some value in it.
This is still a work in progress:
- [x] I need to write some test cases.
- [x] Accessing the CodeMap should really be dependency tracked too, especially with the new path-remapping feature.
cc @nikomatsakis
|
|
Allow bare CR in ////-style comment.
Fixes #40624 in a way that bare CR is allowed in all non-doc comments.
|
|
Use diagnostics for trace_macro instead of println
When using `trace_macro`, use `span_label`s instead of `println`:
```rust
note: trace_macro
--> $DIR/trace-macro.rs:14:5
|
14 | println!("Hello, World!");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: expands to `println! { "Hello, World!" }`
= note: expands to `print! { concat ! ( "Hello, World!" , "\n" ) }`
```
Fix #22597.
|
|
|
|
|
|
|
|
Delete features which are easily removed, in libsyntax
|
|
|
|
Increase macro recursion limit to 1024
Fixes #22552
|
|
|
|
|
|
|
|
Suggest `!` for bitwise negation when encountering a `~`
Fix #41679
Here is a program
```rust
fn main() {
let x = ~1;
}
```
It's output:
```
error: `~` can not be used as an unary operator
--> /home/fcc/temp/test.rs:4:13
|
4 | let x = ~1;
| ^^
|
= help: use `!` instead of `~` if you meant to bitwise negation
```
cc @bstrie
|
|
Add option to display warnings in rustdoc
Part of #41574.
r? @alexcrichton
The output for this file:
```rust
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// panic!();
/// ```
fn foo() {}
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// ```
fn foo2() {}
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// panic!();
/// ```
fn foo3() {}
fn main() {
}
```
is the following:
```
> ./build/x86_64-apple-darwin/stage1/bin/rustdoc -Z unstable-options --display-warnings --test test.rs
running 3 tests
test test.rs - foo (line 1) ... FAILED
test test.rs - foo3 (line 18) ... FAILED
test test.rs - foo2 (line 10) ... ok
successes:
---- test.rs - foo2 (line 10) stdout ----
warning: unused variable: `x`
--> <anon>:2:8
|
2 | fn foo(x: u32) {}
| ^
|
= note: #[warn(unused_variables)] on by default
warning: unused variable: `x`
--> <anon>:5:5
|
5 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
successes:
test.rs - foo2 (line 10)
failures:
---- test.rs - foo (line 1) stdout ----
warning: unused variable: `x`
--> <anon>:2:8
|
2 | fn foo(x: u32) {}
| ^
|
= note: #[warn(unused_variables)] on by default
warning: unused variable: `x`
--> <anon>:5:5
|
5 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
thread 'rustc' panicked at 'test executable failed:
thread 'main' panicked at 'explicit panic', <anon>:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.
', src/librustdoc/test.rs:317
note: Run with `RUST_BACKTRACE=1` for a backtrace.
---- test.rs - foo3 (line 18) stdout ----
warning: unused variable: `x`
--> <anon>:2:8
|
2 | fn foo(x: u32) {}
| ^
|
= note: #[warn(unused_variables)] on by default
warning: unused variable: `x`
--> <anon>:5:5
|
5 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
thread 'rustc' panicked at 'test executable failed:
thread 'main' panicked at 'explicit panic', <anon>:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.
', src/librustdoc/test.rs:317
failures:
test.rs - foo (line 1)
test.rs - foo3 (line 18)
test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured
```
|
|
|
|
|
|
The bound is not required for compiling but it prevents using `next_token()` from a trait object.
Fixes #33506.
|
|
Removal pass for anonymous parameters
Removes occurences of anonymous parameters from the
rustc codebase, as they are to be deprecated.
See issue #41686 and RFC 1685.
r? @frewsxcv
|
|
Removes occurences of anonymous parameters from the
rustc codebase, as they are to be deprecated.
See issue #41686 and RFC 1685.
|
|
Minimize single span suggestions into a label
changes
```
14 | println!("☃{}", tup[0]);
| ^^^^^^
|
help: to access tuple elements, use tuple indexing syntax as shown
| println!("☃{}", tup.0);
```
into
```
14 | println!("☃{}", tup[0]);
| ^^^^^^ to access tuple elements, use `tup.0`
```
Also makes suggestions explicit in the backend in preparation of adding multiple suggestions to a single diagnostic. Currently that's already possible, but results in a full help message + modified code snippet per suggestion, and has no rate limit (might show 100+ suggestions).
|
|
|
|
When -Z profile is passed, the GCDAProfiling LLVM pass is added
to the pipeline, which uses debug information to instrument the IR.
After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno
file is created, containing initial profiling information.
After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda
file is created, containing branch counters.
The created *.gcno and *.gcda files can be processed using
the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM
generates does not faithfully follow the GCC's format for *.gcno
and *.gcda files, and so it will probably not work with other tools
(such as gcov itself) that consume these files.
|
|
syntax: Parse trait object types starting with a lifetime bound
Fixes https://github.com/rust-lang/rust/issues/39085
This was originally implemented in https://github.com/rust-lang/rust/pull/40043, then reverted, then there was some [agreement](https://github.com/rust-lang/rust/issues/39318#issuecomment-289108720) that it should be supported.
(This is hopefully the last PR related to bound parsing.)
|
|
Implement a file-path remapping feature in support of debuginfo and reproducible builds
This PR adds the `-Zremap-path-prefix-from`/`-Zremap-path-prefix-to` commandline option pair and is a more general implementation of #41419. As opposed to the previous attempt, this implementation should enable reproducible builds regardless of the working directory of the compiler.
This implementation of the feature is more general in the sense that the re-mapping will affect *all* paths the compiler emits, including the ones in error messages.
r? @alexcrichton
|
|
#37653 support `default impl` for specialization
this commit implements the first step of the `default impl` feature:
> all items in a `default impl` are (implicitly) `default` and hence
> specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See [referenced](https://github.com/rust-lang/rust/issues/37653) issue for further info
r? @aturon
|
|
`[default] [unsafe] impl` and typecheck
|
|
reproducible builds.
|
|
|
|
|
|
|
|
|
|
|
|
|
