Previously when breaking tokens into smaller pieces, the replace_token
function have been used. It replaced current token and updated span
information, but it did not clear the list of expected tokens, neither
did it update remaining info about last token. This could lead to
incorrect error message, like one described in the issue #24780:
expected one of ... `>` ... found `>`
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes#21000, #25845, and #25846.
Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138
Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.
There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.
Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409
Thanks!
r? @brson
Any documentation comments that contain raw-string-looking sequences may pretty-print invalid code when expanding them, as the current logic always uses the `r"literal"` form, without appending any `#`s.
This commit calculates the minimum number of `#`s required to wrap a comment correctly and appends `#`s appropriately.
Fixes#27489.
Pretty printing of macro with braces but without terminated semicolon
removed more boxes from stack than it put there, resulting in panic.
This fixes the issue #30731.
Rustdoc could trigger a code path that relied on the
$CFG_COMPILER_HOST_TRIPLE environment variable being
set, causing an ICE if it was not. This fixes that,
emitting an error instead of crashing.
Pretty printing of macro with braces but without terminated semicolon
removed more boxes from stack than it put there, resulting in panic.
This fixes the issue #30731.
This is a work in progress PR that potentially should fix#29084, #28308, #25385, #28288, #31011. I think this may also adresse parts of #2887.
The problem in this issues seems to be that when transcribing macro arguments, we just clone the argument Nonterminal, which still has to original spans. This leads to the unprintable spans. One solution would be to update the spans of the inserted argument to match the argument in the macro definition. So for [this testcase](https://github.com/rust-lang/rust/compare/master...fhahn:macro-ice?expand=1#diff-f7def7420c51621640707b6337726876R2) the error message would be displayed in the macro definition:
src/test/compile-fail/issue-31011.rs:4:12: 4:22 error: attempted access of field `trace` on type `&T`, but no field with that name was found
src/test/compile-fail/issue-31011.rs:4 if $ctx.trace {
Currently I've added a very simple `update_span` function, which updates the span of the outer-most expression of a `NtExpr`, but this `update_span` function should be updated to handle all Nonterminals. But I'm pretty new to the macro system and would like to check if this approach makes sense, before doing that.
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.
Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
This PR adds some minor error correction to the parser - if there is a missing ident, we recover and carry on. It also makes compilation more robust so that non-fatal errors (which is still most of them, unfortunately) in parsing do not cause us to abort compilation. The effect is that a program with a missing or incorrect ident can get all the way to type checking.
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.
Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
The protocol for `serialize::{En,De}code` doesn't allow for two
integers to be serialized next to each other. This switches the
protocol to serializing `Span`s as a struct. rbml structs don't
have any overhead, so the metadata shouldn't increase in size,
but it allows the json format to be properly generated, albeit
slightly more heavy than when it was just serializing a span as
a u64.
Closes#31025.
s
Any documentation comments that contain raw-string-looking sequences may
pretty-print invalid code when expanding them, as the current logic
always uses the `r"literal"` form, without appending any `#`s.
This commit calculates the minimum number of `#`s required to wrap a
comment correctly and appends `#`s appropriately.
Fixes#27489.
This aligns with unicode recommendations and should be stable for all future
unicode releases. See http://unicode.org/reports/tr31/#R3.
This renames `libsyntax::lexer::is_whitespace` to `is_pattern_whitespace`
so potentially breaks users of libsyntax.
There is now more structure to the report, so that you can specify e.g. an RFC/PR/issue number and other explanatory details.
Example message:
```
type-parameter-invalid-lint.rs:14:8: 14:9 error: defaults for type parameters are only allowed on type definitions, like `struct` or `enum`
type-parameter-invalid-lint.rs:14 fn avg<T=i32>(_: T) {}
^
type-parameter-invalid-lint.rs:14:8: 14:9 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
type-parameter-invalid-lint.rs:14:8: 14:9 note: for more information, see PR 30742 <https://github.com/rust-lang/rust/pull/30724>
type-parameter-invalid-lint.rs:11:9: 11:28 note: lint level defined here
type-parameter-invalid-lint.rs:11 #![deny(future_incompatible)]
^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
```
r? @brson
I would really like feedback also on the specific messages!
Fixes#30746
This is achieved by adding the scan_back method. This method looks back
through the source_text of the StringReader until it finds the target
char, returning it's offset in the source. We use this method to find
the offset of the opening single quote, and use that offset as the start
of the error.
Given this code:
```rust
fn main() {
let _ = 'abcd';
}
```
The compiler would give a message like:
```
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
```
With this change, the message now displays:
```
error: character literal may only contain one codepoint: 'abcd';
let _ = 'abcd';
^~~~~~~
```
Fixes#30033
