| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
HIR::LoopExpr
|
|
|
|
1283: const folding in gccrs: remove ConstCtx class. r=philberty a=abbasfaisal
Card: [Link](https://github.com/Rust-GCC/gccrs/projects/16#card-82300522)
This class had potential to hinder porting further const folding code from C++. This edit makes it easy to copy code from constexpr.cc to rust-constexpr.cc and so on.
Structs `constexpr_ctx` and `constexpr_global_ctx` have been copied as well as to keep `constexpr_ops_count` after removing the class. These structs will be filled further as the port carries on. The prototypes inside ConstCtx have been copied over to rust-constexpr.cc as static prototypes.
Co-authored-by: Faisal Abbas <90.abbasfaisal@gmail.com>
|
|
1280: Str's have the same layout as [T] r=philberty a=philberty
Raw strings have a very specific type layout which maps over to Slices. It
also has very specific type checking rules so for example:
let a:&str = "TEST 1";
let b:&str = &"TEST 2";
Are both the same type this is likely to be for all DST's but lets do one
rule at a time.
Fixes #1023 #1271
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
This class has potential to hinder porting further const folding code from C++.
So this edit makes it easy to copy code from constexpr.cc to rust-constexpr.cc
and so on.
Signed-off-by: Faisal Abbas <90.abbasfaisal@gmail.com>
|
|
This bug was fixed in commit cb4d935508def8b250345ba5205a90ad9e177ab4
with related PR #1223
The issue is that associated tpyes get updated depending on the context
they are used so we need to monomorphize the types when we can so that we
don't then throw off the rest of typechecking with bogus errors like this.
Fixes #1237
|
|
1278: Remove inside_loop parameter r=philberty a=philberty
The parameter was a hack used to support error handling cases
in Break and Continue expression's but this is no longer required.
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
Raw strings have a very specific type layout which maps over to Slices. It
also has very specific type checking rules so for example:
let a:&str = "TEST 1";
let b:&str = &"TEST 2";
Are both the same type this is likely to be for all DST's but lets do one
rule at a time.
Fixes #1023 #1271
|
|
We already have a Context object containing info about loop contexts. This
removes the need for us to pass this variable around simplifying the type
resolution code. The parameter was a hack used to support error handling
cases in Break and Continue expression's but this is no longer required.
|
|
1275: Remove old hack to handle type inferencing in untyped decalred bindings r=philberty a=philberty
This reverts the code fix for 89631998d2ffda0c0c05066c148c6fc19398da5c
but keeps the test-case proving that we have not regressed. More info in
the commit message.
Fixes #1274 #1273
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
1279: Implement type checking for the `IfLet` expression. r=philberty a=antego
Addresses #1177.
This change implements the type check for the `IfLet` expression. This is the adapted type checking code from the `MatchExpr`.
Tested on this code
```
enum E {
X(u8),
}
fn main() -> i32 {
let mut res = 0;
let v = E::X(4);
if let E::X(n) = v {
res = n;
}
0
}
```
Compilation finishes without errors.
Next is the implementation of the code generation but I'll need help to find where it's located.
Co-authored-by: antego <antego@users.noreply.github.com>
|
|
In the case where you define let a; with no type to then use this binding
and let type inferencing infer the type we used this code to implicitly
generate a new type binding to the resolved node id of the the lvalue.
This was very dangerous and was always meant to be a stop gap untill we
supported more of type inferencing. The issue here was that we were badly
overriting a function types within the type-context which hits an ICE
in the method resolution code which is expecting function TyTy's within
in order to match methods correctly.
Fixes #1274 #1273
|
|
1277: Reuse index_expr_ty type r=philberty a=philberty
This is a small refactor to remove duplicating the work in type checking
the index expression.
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
|
|
|
|
|
|
1268: Fix Slice Type Layout r=philberty a=philberty
Slices in Rust are represented by TypePaths such as '[i32]'. Though if you
actually try to use this explicit type-path you will hit errors such as
this type has an unknown size at compile time. This is because this is
actually what Rust calls a dynamically sized type. This means when you use
types such as: '&[i32]' it is not actually a reference type to a slice. Its
a slice in its entirety this means for lack of a better word when you use
'*const [i32]' or '&mut [i32]' we end up actually passing around a struct
by value _not_ at pointer/reference to it.
This patch changes the type-layout so that we handle this layout change
properly. This patch will also need to be applied to str types which I
believe have a similar layout for safety.
The patch also sets up TYPE_MAIN_VARIANT so that we can avoid unnessecary
view_convert_expressions between *const [i32] and &mut [i32] which will
have the same layout.
Reference:
https://doc.rust-lang.org/reference/dynamically-sized-types.html
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=672adac002939a2dab43b8d231adc1dc
Fixes #1232
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
1241: Implement name resolution for the IfLet expression. r=philberty a=antego
Addresses #1177.
Guidance from the ticket #1177:
> You should be able to copy how we do name resolution for the if blocks from that file. Though if let statements add a new binding and scope level so you need to declare the pattern so you should be able to see how that is done from rust-ast-resolve-stmt.
I don't understand how to modify the block expression resolution so that it can handle the `IfLet` expression. For now, I copied the code from the `MatchExpr` resolution. Not sure how to test it either and what is the desired expected result of the name resolution so I just hope that reviewers will spot the errors.
I created this PR in order to get some guidance about how to proceed with it. Thanks!
Co-authored-by: antego <antego@users.noreply.github.com>
|
|
Slices in Rust are represented by TypePaths such as '[i32]'. Though if you
actually try to use this explicit type-path you will hit errors such as
this type has an unknown size at compile time. This is because this is
actually what Rust calls a dynamically sized type. This means when you use
types such as: '&[i32]' it is not actually a reference type to a slice. Its
a slice in its entirety this means for lack of a better word when you use
'*const [i32]' or '&mut [i32]' we end up actually passing around a struct
by value _not_ at pointer/reference to it.
This patch changes the type-layout so that we handle this layout change
properly. This patch will also need to be applied to str types which I
believe have a similar layout for safety.
The patch also sets up TYPE_MAIN_VARIANT so that we can avoid unnessecary
view_convert_expressions between *const [i32] and &mut [i32] which will
have the same layout.
Reference:
https://doc.rust-lang.org/reference/dynamically-sized-types.html
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=672adac002939a2dab43b8d231adc1dc
Fixes #1232
|
|
In the case of Generic Associated Types we end up
placeholders->projections->generic-param->i32
This means we need to keep destructuring the TyTy object until we finally
get the real type at the end. In order to do this safely we need to ensure
we add in recursion limits and apply this where it matters such as
compiling types in general too.
|
|
1267: Marklive: support match expr r=philberty a=thomasyonug
This makes `MarkLive` support `HIR::MatchExpr` and adds a related test case.
Co-authored-by: Thomas Young <wenzhang5800@gmail.com>
|
|
|
|
This reverts commit 75c9f9f61cb2d69f39d490c47a3b42810c31c1ff. Which was
accidently pushed to master outside of the PR system. No harm done :).
Happy hacking.
|
|
|
|
When we compile types for GCC we need to make sure we canonicalize them,
this means that for any user defined type such as Structs or Tuples we want
all expressions or declarations to use the same tree. Even if we have
duplicate tree's we can end up confusing the middle-end and lose out on
optimizations as we will be using view_convert_exprs to maintain the
consistancy which will marshall between the objects unnessecarily.
The old method for doing this kept mappings of HirIds which was fine for
simple cases but when generics are involved new Id's are generated so this
meant we ended up having a vector of pairs {TyTy::BaseType, tree} and we
did a liner search to find the relevant TyTy::BaseType that we equaled to.
This was not only slow but did not handle the cases for generic associated
types or nested generics. So we needed a more general faster implementation
therefore hashing. This patch takes the gcc/tree.h type_hash_canon code
and adds in hashing for RECORD and UNION types. This means we will generate
a duplicate type then hash it and look for an existing type.
This patch will also allow us to fix how we implement monomorphization of
functions by nesting the hashes behind DefId's.
|
|
|
|
privacy: Circumvent weird behavior about inference types for now
The issue we're facing is detailed in #1260. It's not necessary to fix
now to have a good type privacy base
privacy: PrivacyReporter: Handle projections and placeholders
|
|
|
|
1255: Privacy report expressions r=CohenArthur a=CohenArthur
This adds privacy reporting to all expression types inside our HIR. It also restricts the `PrivacyReporter` visitor to `HIR::Expression`s and `HIR::Stmt`s as a lot of the previous types did not need to be visited.
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
1252: privacy: Handle calls to functions defined in previous ancestors r=CohenArthur a=CohenArthur
Previously, we would only check if `current_module` was a direct
descendant of the item's module. However, we also need to visit each of this
item's module's children recursively.
1254: issue #1233: Do not rely on the endianness for testing r=CohenArthur a=CohenArthur
This testcase uncovered a very interesting bug requiring a refactor of
our `AST::Block` class (#1253), but should still be fixed/adapted in the
meantime so that the BE builds on our buildbot do not fail.
I've tested this newtestcase with a compiler from 74e836599ce80a11b1fe28065ed7aae6ffa3b7e2, which was the commit pointed out in #1233. The same ICE would still trigger, so I can safely say that this is a different exemple showing the same underlying issue. I'll work on fixing #1253 but it is a refactor we need to think about a little.
This should make all the architectures on buildbot happy again!
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
1250: Support extern-blocks defined within blocks r=philberty a=philberty
This adds support for declaring extern blocks within blocks. So this adds
the missing name resolution visitor for the statement context. Then we
extract out a common extern block hir lowering function for both contexts.
The type resolution step needs to be updated to be like the code-generation
step so that we can solve these paths in a query rather than a top-down
approach but this is a known issue.
The final step was to support query-based compilation to extern functions.
Fixes #976
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
|
|
|
|
This testcase uncovered a very interesting bug requiring a refactor of
our `AST::Block` class (#1253), but should still be fixed/adapted in the
meantime so that the BE builds on our buildbot do not fail.
|
|
Previously, we would only check if `current_module` was a direct
descendant of the item's module. However, we also need to visit each of this
item's module's children recursively.
|
|
This adds support for declaring extern blocks within blocks. So this adds
the missing name resolution visitor for the statement context. Then we
extract out a common extern block hir lowering function for both contexts.
The type resolution step needs to be updated to be like the code-generation
step so that we can solve these paths in a query rather than a top down
approach but this is a known issue.
The final step was to support query based compilation to extern functions.
Fixes #976
|
|
1246: Report simple privacy violations r=CohenArthur a=CohenArthur
This adds a base visitor for reporting basic privacy violations. For now, only function calls are implemented.
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sadly, this requires specializing the class to keep the underlying pointer of
the reference.
|
|
1244: Allow match on integer and char types r=dafaust a=dafaust
Enable compiling match expressions on other primitive types like `i32`, `usize` and `char`.
Co-authored-by: David Faust <david.faust@oracle.com>
|
|
This patch enables compiling match expressions for other primitive
types, like int and char. However, we cannot currently compile matches
on floats; CASE_LABEL_EXPR doesn't support floating-point types.
|
|
|
