{"push_id":2503620543,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"2f782d403ae5729b6c93fbe92577ee01f7a8d608","before":"c73ccbc5616dff16ecacb9198f725f498a7e6c84","commits":[{"sha":"2f782d403ae5729b6c93fbe92577ee01f7a8d608","author":{"name":"Tim Foley","email":"0f43a94916e812ec0de8effd5dca59a0081c6335@users.noreply.github.com"},"message":"Diagnose use of an implicit cast as an argument for an `out` parameter (#516)\n\nWork on #499\r\n\r\nTwo big fixes here:\r\n\r\n* The logic for checking constraints on `out` arguments wasn't actually triggering because it relied on function parameters being given an `OutType` if they are marked `out`, but the code wasn't actually doing that. Fixing the computation of types for functions resolved that issue.\r\n\r\n* Next, I added a specific diagnostic to follow up the \"expected an l-value\" error to let the user know that their argument was implicitly converted, and that is why it doesn't count as an l-value in Slang's rules.\r\n\r\nI've added a test case to ensure that we retain this diagnostic until we can do a true fix for the issue.\r\n\r\nThe right long-term fix is to have an AST representation of all the implicit casts involved (e.g., in both directions for an `inout` parameter), and then have the IR generate explicit code for the conversions in each direction (the `LoweredVal` representation can handle this sort of thing).","distinct":true,"url":"https://api.github.com/repos/shader-slang/slang/commits/2f782d403ae5729b6c93fbe92577ee01f7a8d608"}]}
{"actor":{"display_login":"tfoleyNV"}}