This requirement appears to be missing from RFC1214, but is clearly
necessary for translation. The last field of a tuple/enum remains in
a state of limbo, compiling but causing an ICE when it is used - we
should eventually fix that somehow.
this is a [breaking-change] - a soundness fix - and requires a
crater run.
Put a constraint type on every ADT def, such that the ADT def is sized iff the constraint
type is, and use that in selection. This ignores types that are obviously sized.
This improves typeck performance by ~15%.
rustdoc: HTML-escape Rust code (from constants)
Especially in cases like the one in the test file, this can blow up the rendering big time if string constants in the code contain HTML.
But also other constants can contain special chars (e.g. `&` as an operator in constant expressions).
rustdoc: fix inserting source code spans for constant values
This will go wrong when the constants partially result from macro expansion.
Instead, use the expressions and pretty-print them as Rust code.
Fixes: #33302
parser: change warning into an error on `T<A=B, C>`
part of #32214
This seems to be the obvious fix, and the error message is consistent with all the other parser errors ("expected x, found y").
resolve: print location of static for "static in pattern" error
The implementation mirrors the one for "constant defined here" annotation used for constant patterns in the irrefutable-pattern case.
Fixes: #23716
fix various const eval errors
These were found after const_evaluating arbitrary expressions and linting if the const evaluator failed
fixes#33275 (int -> float casts for negative ints)
fixes#33291 (int -> char casts (new! wasn't allowed in constants until this PR))
r? @eddyb
cc @bluss @japaric
doc/book/getting-started.md: Spelling correction and revised wording.
The word 'Internet' was spelt with both an uppercase and a lowercase 'I'. The correct spelling seems to be a matter of some debate these days, however the first occurrence in the file has an uppercase 'I', so I've changed the second occurrence to suit for consistency.
Under the section titled 'Converting to Cargo', there's mention of creating a new executable. This, however, is not part of the process described. I've revised the wording to reflect as much.
Small changes, but I hope they are of benefit! :-)
r? @steveklabnik
Especially in cases like the one in the test file, this can blow
up the docs big time if string constants in the code contain HTML.
But also other constants can contain special chars (e.g. `&` as an
operator in constant expressions).
typeck: when suggesting associated fns, do not show call site as fallback
In case we cannot produce a span for the location of the definition, just do not show a span at all.
cc: #29121
This will go wrong when the constants partially result from macro expansion.
Instead, use the expressions and pretty-print them as Rust code.
Fixes: #33302
docs: Changed docs for `size_of` to describe size as a stride offset
Current documentation for `std::mem::size_of` is ambiguous, and the documentation for `std::intrinsics::size_of` incorrectly defines size.
This fix re-defines size as the offset in bytes between successive instances of a type, as described in LLVM's [getTypeAllocSize](http://llvm.org/docs/doxygen/html/classllvm_1_1DataLayout.html#a1d6fcc02e91ba24510aba42660c90e29).
Fixes: #33266
lexer: do not display char confusingly in error message
Current code leads to messages like `... use a \xHH escape: \u{e4}` which is confusing.
The printed span already points to the offending character, which should be enough to identify the non-ASCII problem.
Fixes: #29088
rustc: Handle concurrent `create_dir` requests
The compiler created a directory as part of `-Z incremental` but that may be
hierarchically used concurrently so we need to protect ourselves against that.
typeck: remove confusing suggestion for calling a fn type
* It is not clear what a "base function" is.
* The suggestion just adds parens, so suggests calling without args.
The second point could be fixed with e.g. `(...)` instead of `()`,
but the preceding "note: X is a function, perhaps you wish to call it"
should already be clear enough.
Fixes: #31341
E0269: add suggestion to check for trailing semicolons
In situations where the value of the last expression must be inferred,
rustc will not emit the "you might need to remove the semicolon" warning,
so at least note this in the extended description.
Fixes: #30497
match check: note "catchall" patterns in unreachable error
Caught as catchall patterns are:
* unconditional name bindings
* references to them
* tuple bindings with catchall elements
Fixes#31221.
diagnostics for E0432: imports are relative to crate root
This is curiously missing from both the short message and this long diagnostic.
Refs #31573 (not sure if it should be considered "fixed" as the short message still only refers to extern crates).
Overhaul borrowck error messages and compiler error formatting generally
This is a major overhaul of how the compiler reports errors. The primary goal is to be able to give many spans within the same overall context, such as this:
```
./borrow-errors.rs:73:17: 73:20: error: cannot borrow `*vec` as immutable because previous closure requires unique access [E0501]
70 let append = |e| {
~~~ closure construction occurs here
71 vec.push(e)
~~~ previous borrow occurs due to use of `vec` in closure
72 };
73 let data = &vec[3];
~~~ borrow occurs here
74 }
~ borrow from closure ends here
```
However, in the process we made a number of other changes:
- Removed the repetitive filenames from snippets and just give the line number.
- Color the line numbers blue so they "fade away"
- Remove the file name and line number from the error code suggestions since they don't seem to fit anymore. (This should probably happen in more places, like existing notes.)
- Newlines in between errors to help group them better.
This PR is not quite ready to land, but we thought it made sense to stop here and get some feedback from people at large. It'd be great if people can check out the branch and play with it. We'd be especially interested in hearing about cases that don't look good with the new formatting (I suspect they exist).
Here is a checklist of some pending work items for this PR. Some of them may be best left for follow-up PRs:
- [x] Accommodate multiple files in a `MultiSpan` (this should be easy)
- In this case, we want to print filenames though.
- [x] Remove duplicate E0500 code.
- [x] Make the header message bold, rather than current hack that makes all errors/warnings bold
- [x] Update warning text color (yellow is hard to read w/ a white background)
Moved numerous follow-ups to: https://github.com/rust-lang/rust/issues/33240
Joint work with @jonathandturner.
Fixes https://github.com/rust-lang/rust/issues/3533
Overhaul borrowck error messages and compiler error formatting generally
This is a major overhaul of how the compiler reports errors. The primary goal is to be able to give many spans within the same overall context, such as this:
```
./borrow-errors.rs:73:17: 73:20: error: cannot borrow `*vec` as immutable because previous closure requires unique access [E0501]
70 let append = |e| {
~~~ closure construction occurs here
71 vec.push(e)
~~~ previous borrow occurs due to use of `vec` in closure
72 };
73 let data = &vec[3];
~~~ borrow occurs here
74 }
~ borrow from closure ends here
```
However, in the process we made a number of other changes:
- Removed the repetitive filenames from snippets and just give the line number.
- Color the line numbers blue so they "fade away"
- Remove the file name and line number from the error code suggestions since they don't seem to fit anymore. (This should probably happen in more places, like existing notes.)
- Newlines in between errors to help group them better.
This PR is not quite ready to land, but we thought it made sense to stop here and get some feedback from people at large. It'd be great if people can check out the branch and play with it. We'd be especially interested in hearing about cases that don't look good with the new formatting (I suspect they exist).
Here is a checklist of some pending work items for this PR. Some of them may be best left for follow-up PRs:
- [x] Accommodate multiple files in a `MultiSpan` (this should be easy)
- In this case, we want to print filenames though.
- [x] Remove duplicate E0500 code.
- [x] Make the header message bold, rather than current hack that makes all errors/warnings bold
- [x] Update warning text color (yellow is hard to read w/ a white background)
Moved numerous follow-ups to: https://github.com/rust-lang/rust/issues/33240
Joint work with @jonathandturner.
Fixes https://github.com/rust-lang/rust/issues/3533
