Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2023-06-30T19:25:59+00:00 2023-06-30T19:25:59+00:00 jsmall-nvidia jsmall@nvidia.com 2023-06-30T19:25:59+00:00 urn:sha1:c5b0708ead5de2d90ef14f20b5b8e3ed4f576373 * WIP handling LValue coercion via LValueImplicitCast * Need to have the ptr type for the cast. * Casting conversion working on C++. * Make the LValue casts record if in or in/out as we can produce better code if we know the difference. * WIP LValueCast pass * Fix tests so we don't fail because downstream compilers detect use of uninitialized variable. * Do conversions through through tmp for l-value scenarios that can't work other ways. * Fix a typo. * Change diagnostic implicit-cast-lvalue for a type that still exhibits the issue. * Add matrix test. * Added a bit more clarity around LValue casting choices. * Small comment improvements. Improvements based on comments on PR. * Use findOuterGeneric. 2019-04-02T13:22:13+00:00 jsmall-nvidia jsmall@nvidia.com 2019-04-02T13:22:13+00:00 urn:sha1:2896aa39a529a00673a30ef4a9c3ebe76f401fea * First pass extract the test information by 'running tests'. * * Checking renderer availablilty * Using TestInfo to determine which tests are run and synthesized * Display if test is synthesized and what render api it's targetting * * Improved comments * Removed some dead code * Display ignored tests. * TestInfo -> TestRequirements * * Added DIAGNOSTIC_TEST type - test always runs (ie has no requirements). * Made diagnostic tests use DIAGNOSTIC_TEST * TestInfo -> TestRequirements * TestDetails holds TestRequirements and TestOptions * Fix debug typo. 2018-04-20T23:56:33+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2018-04-20T23:56:33+00:00 urn:sha1:2f782d403ae5729b6c93fbe92577ee01f7a8d608 Work on #499 Two big fixes here: * 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. * 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. I've added a test case to ensure that we retain this diagnostic until we can do a true fix for the issue. The 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).