this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
fixes#30887
r? @pnkfelix
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.
This adds back the raw_pointer_derive lint as a 'removed' lint, so that its removal does not cause errors (#30346) but warnings.
In the process I discovered regressions in the code for renamed and removed lints, which didn't appear to have any tests. The addition of a second lint pass (ast vs. hir) meant that attributes were being inspected twice, renamed and removed warnings printed twice. I restructured the code so these tests are only done once and added tests. Unfortunately it makes the patch more complicated for the needed beta backport.
r? @nikomatsakis
This provides limited support for using associated consts on type parameters. It generally works on things that can be figured out at trans time. This doesn't work for array lengths or match arms. I have another patch to make it work in const expressions.
CC @eddyb @nikomatsakis
This PR changes translation of tuple-like ADTs from being calls to being proper aggregates. This change is done in hope to make code generation better. Namely, now we can avoid:
1. Call overhead;
2. Generating landingpads in presence of cleanups (we know for sure constructing ADTs can’t panic);
3. And probably much more, gaining better MIR introspectablilty.
Along with that a few serious deficiencies with translation of ADTs and switches have been fixed as well (commits 2 and 3).
r? @nikomatsakis
cc @tsion
In my PR for #21659 I accidentally used `// | help` as test annotation. This PR updates it to `//~| help`. I also found and updated 2 other tests with the same issue.
The only way to get a value for a zero-sized type is `undef`, so
there's really no point in actually having a return type other than
void for such types. Also, while the comment in return_type_is_void
mentioned something about aiding C ABI support, @eddyb correctly
pointed out on IRC that there is no such thing as a zero-sized type in
C. And even with clang, which allows empty structs, those get
translated as void return types as well.
Fixes#28766
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
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
[breaking-change]
`OptLevel` variants are no longer `pub use`ed by rust::session::config. If you are using these variants, you must change your code to prefix the variant name with `OptLevel`.
Given this code:
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
Put back alloca zeroing for issues #29092, #30018, #30530; inject zeroing for #30822.
----
Background context: `fn alloca_zeroed` was removed in PR #22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's.
----
I first fixed#30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of #30530.
While making the regression test for the latter, I discovered #30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant.
I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action).
----
(*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value.
Fix#29092Fix#30018Fix#30530Fix#30822
This PR fixes an ICE due to an DiagnosticsBuilder not being canceld or emitted.
Ideally it would use `Handler::cancel`, but I did not manage to get a `&mut` reference to the diagnostics handler.
This is an alternative to https://github.com/rust-lang/rust/pull/29954 for fixing #29857 that seems to me to be more inline with the general strategy around `TyError`. It also includes the fix for #30589 -- in fact, just the minimal change of making `ty_is_local` tolerate `TyError` avoids the ICE, but you get a lot of duplicate error reports, so in the case where the impl's trait reference already includes `TyError`, we just ignore the impl altogether.
cc @arielb1 @sanxiyn
Fixes#29857.
Fixes#30589.
Downgrade unit struct match via S(..) warnings to errors
The error signalling was introduced in #29383
It was noted as a warning-cycle-less regression in #30379Fix#30379
Fixes#30674
The test seems to work fine and assertion passes. The test seems to also be generated from MIR (LLVM IR has footprint of MIR translator), thus I’m reenabling it.
